> On Aug 17, 2016, at 9:36 AM, Masakazu Kitajo <mas...@apache.org> wrote: > > I realized that URL class isn't exposed as a part of TS API. None of > APIs receive it explicitly, and TSMLoc is used instead.
This is the approach that the recent TSHttpTxnCacheLookupUrlGet API took. We should take a consistent approach across the API. Its confusing and harder than necessary when some APIs take strings and some take TS objects. > Also, I > couldn't overload the API because it's not C++ but C. Why did you want to overload it? > > So, I think passing URLs as strings is a reasonable way, and it is the > only option for now. > > I'm going to start writing documentation this weekend and merge the > Pull Request by next weekend. Please comment if you have any thoughts. > This would be the final call since there's no responses in last 10 > days. > > Thanks > > > > On Sat, Aug 6, 2016 at 6:13 PM, Masakazu Kitajo <mas...@apache.org> wrote: >> What do you think about providing the both interfaces? >> >> I'm fine with passing URL objects internally. However, I guess there >> are cases that URL strings comes from out of TS APIs such as >> databases, results of some processing, etc. Though people can create >> URL objects easily, it needs few more boring codes in every plugins. >> >> >> On Sat, Aug 6, 2016 at 12:08 AM, Leif Hedstrom <zw...@apache.org> wrote: >>> >>>> On Aug 4, 2016, at 8:15 PM, James Peach <jpe...@apache.org> wrote: >>>> >>>> >>>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <mas...@apache.org> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'd like to add a new API to support Server Push[1] introduced by HTTP/2. >>>>> >>>>> void TSHttpTxnServerPush(TSHttpTxn txnp, const char *url, int url_len) >>>> >>>> I think the direction we are moving in is to pass URLs as URL objects >>>> rather than strings. >>> >>> >>> Definitely. >>> >>> — leif >>> >>>> >>>>> >>>>> This allows plugins to push contents with Server Push mechanism >>>>> supported by client session protocols. Currently, the API can be used >>>>> with HTTP/2 sessions but it will be used with QUIC[2] sessions too in >>>>> the future. >>>>> >>>>> I think the API should be marked as experimental, and it need to be >>>>> brushed up with practical use cases. However, at least, it should >>>>> satisfy the simple approaches discussed on TS-3474. >>>>> >>>>> JIRA: >>>>> https://issues.apache.org/jira/browse/TS-3474 >>>>> >>>>> Pull Request: >>>>> https://github.com/apache/trafficserver/pull/833 >>>>> >>>>> [1] https://tools.ietf.org/html/rfc7540#section-8.2 >>>>> [2] >>>>> https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00#section-9 >>>>> >>>>> Thanks, >>>>> Masakazu >>>> >>>
