- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Mon, 12 Jul 2004 22:53:12 -0600 (MDT)
- To: ietf-http-wg@w3.org
On Mon, 12 Jul 2004, David Morris wrote: > If the proxy implementor can't read and understand the RFC notion of > hop-hop headers, RFC notion is defined by normative rules in the RFC. Please note that current normative rules are incomplete and inconsistent. > how can you have confidence they'll even look at the content header > and use it to control filtering? I am confident that most implementations will remain incompliant even if we fix the spec (compliance is not driven by correct specs). However, leaving the spec buggy, despite real implementors questions/concerns, is bad for everybody involved (compliance with incorrect specs is impossible or meaningless). On Tue, 2004-07-13 at 07:32, David Morris wrote: > There should be an exception for ALL headers declared in the > specification. It is absurd to bloat the size of HTTP headers to > declare information contained in the RFC. I would agree 100% if we were talking about changing an Internet Draft. Unfortunately, we are working in a context of an existing IETF Standard that needs to be fixed. As developer questions and actual implementations indicate the "information contained in the RFC [2616]" is imprecise, inconsistent, or missing, depending on the hop-by-hop header. Existing implementations may honestly forward some hop-by-hop headers (while also honoring the Connection header logic). Thus, we cannot simply reply on [hop-by-hop header] information contained in the RFC". If we add explicit hop-by-hop headers to Connection, the above mentioned implementations will be automatically "fixed" when they receive messages from newer HTTP agents. I suspect that chances of breaking an old implementation by listing explicit hop-by-hop headers are non-zero, but hope that they are negligible. The proposed new wording does two things: 1) documents the intent of the original wording in a normative and consistent way (proxies MUST NOT forward) 2) attempts to increase the probability that old and new implementations will do the right thing (by listing all hop-by-hop headers in the Connection header) I do not have strong feelings about (2). Adding a few bytes to a few messages does not bother me much, but I am worried that, in some corner cases, listing more headers in Connection might expose currently undetected vulnerabilities in old products. I did not hear any objections to (1). Can we declare consensus on that part of the fix? Thank you, Alex.
Received on Tuesday, 13 July 2004 01:02:44 UTC