Re: H2 Implementation Debug State URI

On 08/10/2016 11:39 AM, Mike Bishop wrote:

> The problem is that upstream HPACK context might well contain headers
> from requests that were made by clients other than you. 

It is not a problem under the stated precondition -- "hop that has
allowed its HPACK state sharing". Somebody has made a decision that such
sharing is OK in their specific environment, for that specific request, etc.

And it is easy to make HPACK sharing conditional so that the interface
can remain more open to less dangerous queries:

  # I know you are going to deny my request if I [implicitly] ask for
  # HPACK, so please note that I actually do not want to see it:
  uri = .well-known/h2/state?with-hpack=0

> Leakage
> between connections is a bad thing.  You might be able to turn this
> on for in-depth debugging, but you'd *never* want that bit enabled on
> a live server.

Yes, of course. I doubt any sane admin would enable this debugging by
default in a unprotected environment anyway, with or without HPACK. This
is a triage aid. Code like that is rarely of high quality and must be

These valid security concerns are not tied to the Max-Forwards mechanism
IMHO. This is like telling a carpenter to avoid the really heavy hammer
because somebody will get hurt if that hammer is misused.


> -----Original Message-----
> From: Alex Rousskov [] 
> Sent: Wednesday, August 10, 2016 9:17 AM
> To: Cory Benfield <>
> Cc: HTTP Working Group <>
> Subject: Re: H2 Implementation Debug State URI
> On 08/10/2016 03:50 AM, Cory Benfield wrote:
>> using Max-Forwards is conditional on not dumping HPACK. That may be an 
>> acceptable compromise.
> What is wrong with receiving HPACK state from hop #(N+1) that has allowed its HPACK state sharing, even if you actually asked to see HPACK state of the unsupporting hop #N? I understand that #(N+1) may not be very useful in some triage cases, but I am sure it will be useful in others.
> The Via headers and/or equivalent will tell the client which hop responded to the Max-Forwards:N debugging request (and, in most cases, whether any unsupporting hops were skipped).
> Alex.

Received on Wednesday, 10 August 2016 20:12:24 UTC