Leif and I went through the 7.0.0 bugs this morning and pushed out some bugs
that didn’t have pull requests or looked like they wouldn’t be completed by
9/12. If you have some bug that you are working on for the 7.0.0 release that
were pushed out and still want to get them in, please change the
I just wrote documentation. You can see it on the Pull Request too.
https://github.com/apache/trafficserver/pull/833
TSHttpTxnServerPush
Synopsis
#include
Description
Push a content to a client with Server Push mechanism.
This API works only if the protocol of a transaction supports Server
> On Sep 8, 2016, at 7:55 AM, Sudheer Vinukonda
> wrote:
>
>
>
>> On Sep 7, 2016, at 10:09 PM, James Peach wrote:
>>
>>
>>> On Sep 7, 2016, at 9:16 PM, Sudheer Vinukonda
>>> wrote:
>>>
>>>
>>>
On Sep 7, 2016, at 8:48 PM, James Peach wrote:
> On Sep 7, 2016, at 8:
> On Sep 7, 2016, at 2:09 PM, Susan Hinrichs
> wrote:
>
>
> This is an API we have been using at Yahoo. Originally used to get
> information about SPDY and HTTP2 when they were implemented with the plugin
> interface, but used by other plugin writers to track information about which
> plug
After discussing with the other committers on the project we have decided to
remove the clustering feature in ATS 7.0.0.
There are people in the community that are using configuration management
(Puppet, Chef, Salt, etc.) for large installations. If you need help on
syncing configuration outsi
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.
It's very different for HTTP/2 now because of TS-3612. HTTP/2 does not use
PluginVC nor FetchSM. It is part of core and interacts directly with the HttpSM.
> On Sep 7, 2016, at 10:09 PM, James Peach wrote:
>
>
>> On Sep 7, 2016, at 9:16 PM, Sudheer Vinukonda
>> wrote:
>>
>>
>>
>>> On Sep 7, 2016, at 8:48 PM, James Peach wrote:
>>>
>>>
On Sep 7, 2016, at 8:30 PM, Sudheer Vinukonda
wrote:
I was replying to this -
>>>
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 m
