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 [mailto:rousskov@measurement-factory.com] 
Sent: Wednesday, August 10, 2016 9:17 AM
To: Cory Benfield <cory@lukasa.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 17:40:28 UTC