Re: H2 Implementation Debug State URI

On 08/06/2016 10:33 AM, Cory Benfield wrote:
> 
>> On 5 Aug 2016, at 17:00, Alex Rousskov <rousskov@measurement-factory.com> wrote:
>>
>> On 08/05/2016 03:07 AM, Cory Benfield wrote:
>>
>>> The longer term question is about how to deal with the fact that a
>>> misbehaving H2 connection could be the result of the H2 state in any of
>>> the hops on the connection. For example, if you have a connection that
>>> goes: client -> forward proxy A -> reverse proxy B -> origin server, and
>>> all those hops are H2, you really need to see H2 state in *all* of them
>>> to understand what the problem might be. However, the well-known URI
>>> doesn’t allow for that kind of debugging without requiring the awkward
>>> step of needing proxies to rewrite the response body to include their
>>> own data.
>>
>> If you combine the well-known debugging URI with a Max-Forwards header,
>> then you may get pretty close to the desired "and here is my state too"
>> effect. It is not going to be "the state of each agent at the same
>> moment of time", but nothing is going to give you that precision anyway.

> This was discussed, but was discarded in part because many proxies do not respect that header. 

I do not understand that reasoning: Surely those proxies that add
support for the new feature (debugging URI) can be required to support
Max-Forwards, at least in the context of that feature. Is it really
better to add Max-Forwards-2 or require response body adaptations?


> Additionally, it’s only defined on OPTIONS requests.

It is not prohibited for any other method. TRACE and OPTIONS are the two
methods where the protocol requires certain actions, but that does not
mean new features (like a debugging URI) cannot use it.

Alex.

Received on Monday, 8 August 2016 19:47:59 UTC