- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Wed, 10 Aug 2016 10:50:46 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 9 Aug 2016, at 16:59, Alex Rousskov <rousskov@measurement-factory.com> wrote: > > On 08/09/2016 03:50 AM, Cory Benfield wrote: > >> For those that don’t add support, they blindly forward the request >> on, running the risk of information leakage and invalid/incorrect >> responses. > > I do not see how Max-Forwards unsupporting proxies can have a > significant negative effect on the problem you are trying to solve. > Obviously, you will not get their debugging state, but that is going to > happen no matter what -- there will always be proxies that do not > support your new feature. Why would Max-Forwards unsupporting proxies > produce invalid responses? They will just forward the response the next > hop gives them, and that response would be correct or incorrect > regardless of what they do. > > AFAICT, Max-Forwards essentially lets you interrogate supporting hops. > Unless you change the protocol to require debugging support, nothing you > can do will let you interrogate unsupporting hops. > > This overall problem feels very similar to traceroute -- it does not > always work and not all hops support ICMP TTLs, but it works well enough > in many cases to remain useful. > I think this summary is true if HPACK information is removed from the debugging output. So using Max-Forwards is conditional on not dumping HPACK. That may be an acceptable compromise. Cory
Received on Wednesday, 10 August 2016 09:51:18 UTC