+1 to removing (and setting default to 0)
If we get to the point of getting protocol plugins back (so that we can
support non-http) -- we should make this check pluggable per
protocol-plugin, but since that isn't whats happening-- we can just remove
this one.
On Wed, Jun 29, 2016 at 9:20 PM, Sudh
> On Aug 4, 2016, at 8:15 PM, James Peach wrote:
>
>
>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo 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 thi
Bringing this conversation back to life. We'd like to open source a
plugin which relies on this API (or something like it). There has been
discussion on the PR which James requests that we bring back to the
mailing list.
To catch everyone up to speed with the PR discussion
(https://github.co
> On Aug 6, 2016, at 7:16 AM, Susan Hinrichs
> wrote:
>
> Bringing this conversation back to life. We'd like to open source a plugin
> which relies on this API (or something like it). There has been discussion on
> the PR which James requests that we bring back to the mailing list.
>
> To c
James, I thought your original objection was the API not being sufficiently
generally. I think an API that's just a set of booleans for each possible
protocol is insufficiently general. This style would mean every new protocol
would need new API (e.g. QUIC) whereas with the currently proposed AP
