RE: H2 Implementation Debug State URI

The problem is that upstream HPACK context might well contain headers from requests that were made by clients other than you.  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.

-----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).


Received on Wednesday, 10 August 2016 17:40:28 UTC