You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2016/08/05 02:15:06 UTC
Re: [API PROPOSAL] TSHttpTxnServerPush
> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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.
>
> 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
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Masakazu Kitajo <ma...@apache.org>.
I just wrote documentation. You can see it on the Pull Request too.
https://github.com/apache/trafficserver/pull/833
TSHttpTxnServerPush
Synopsis
#include <ts/experimental.h>
Description
Push a content to a client with Server Push mechanism.
This API works only if the protocol of a transaction supports Server
Push and it is not disabled by the client. You can call this API
without checking whether Server Push is available on the transaction
and it does nothing if Server Push is not available.
Notes
This API may be changed in the future version since it is experimental.
On Fri, Sep 9, 2016 at 12:26 AM, Alan Carroll
<so...@yahoo-inc.com.invalid> wrote:
> I would like some documentation for this API call. I have to clean up an unrelated mess because functions were added but never documented, so let's avoid that in the future.
>
>
>
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Alan Carroll <so...@yahoo-inc.com.INVALID>.
I would like some documentation for this API call. I have to clean up an unrelated mess because functions were added but never documented, so let's avoid that in the future.
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Masakazu Kitajo <ma...@apache.org>.
Passing a URL string go against the recent approach. However, what if
TSHttpTxnCacheLookupUrlSet had not been introduced? Do we choose
passing a URL object for this API? Is there any reason for using URL
objects across the APIs except consistency?
I think both consistency and convenience are for making plugin
development easier, and the most important thing is
straightforwardness.
Everybody please post your thoughts. I'd like to add this API to 7.0 release.
--
Masakazu
On Thu, Aug 18, 2016 at 6:49 AM, Masakazu Kitajo <ma...@apache.org> wrote:
>> 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.
>
> As I wrote on the second to last mail, I guess the URLs would come
> from out of TS APIs. So if we require TSMLoc, it means plugin
> developers need to create a TSMBuffer somehow and pass a offset to a
> URL, to just pass a URL. Is this really convenient to plugin
> developers?
>
>> Why did you want to overload it?
>
> I tried to provide two APIs, URL object version and string version.
> One is for a case that a URL comes from other TS APIs, and another one
> is for a case that a URL comes from out of TS APIs.
>
>
>
> On Thu, Aug 18, 2016 at 5:20 AM, James Peach <jp...@apache.org> wrote:
>>
>>> On Aug 17, 2016, at 9:36 AM, Masakazu Kitajo <ma...@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 <ma...@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 <jp...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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
>>>>>>
>>>>>
>>
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Masakazu Kitajo <ma...@apache.org>.
> 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.
As I wrote on the second to last mail, I guess the URLs would come
from out of TS APIs. So if we require TSMLoc, it means plugin
developers need to create a TSMBuffer somehow and pass a offset to a
URL, to just pass a URL. Is this really convenient to plugin
developers?
> Why did you want to overload it?
I tried to provide two APIs, URL object version and string version.
One is for a case that a URL comes from other TS APIs, and another one
is for a case that a URL comes from out of TS APIs.
On Thu, Aug 18, 2016 at 5:20 AM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 17, 2016, at 9:36 AM, Masakazu Kitajo <ma...@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 <ma...@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 <jp...@apache.org> wrote:
>>>>>
>>>>>
>>>>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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
>>>>>
>>>>
>
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by James Peach <jp...@apache.org>.
> On Aug 17, 2016, at 9:36 AM, Masakazu Kitajo <ma...@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 <ma...@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 <jp...@apache.org> wrote:
>>>>
>>>>
>>>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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
>>>>
>>>
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Masakazu Kitajo <ma...@apache.org>.
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. Also, I
couldn't overload the API because it's not C++ but C.
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 <ma...@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 <jp...@apache.org> wrote:
>>>
>>>
>>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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
>>>
>>
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Masakazu Kitajo <ma...@apache.org>.
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 <jp...@apache.org> wrote:
>>
>>
>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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
>>
>
Re: [API PROPOSAL] TSHttpTxnServerPush
Posted by Leif Hedstrom <zw...@apache.org>.
> On Aug 4, 2016, at 8:15 PM, James Peach <jp...@apache.org> wrote:
>
>
>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <ma...@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
>