W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2002

Re: TE header

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Mon, 5 Aug 2002 13:01:05 -0600 (MDT)
To: Jeffrey Mogul <Jeff.Mogul@hp.com>
cc: Joe Orton <joe@manyfish.co.uk>, ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.10.10208051253350.91722-100000@measurement-factory.com>

On Mon, 5 Aug 2002, Jeffrey Mogul wrote:

> Joe Orton writes:
>     I'm confused by this paragraph in section 14.39 of 2616:
>        The TE header field only applies to the immediate connection.
>        Therefore, the keyword MUST be supplied within a Connection header
>        field (section 14.10) whenever TE is present in an HTTP/1.1 message.
> Alex Rousskov writes:
>     The MUST clause wording is clearly buggy. The clause should
>     either be deleted or reworded to specify a different reason.
> No, the MUST clause is correct.  Consider this scenario:
> HTTP/1.1 client sends this request to RFC2068-compliant proxy:

I have to disagree. Yes, the _result_ of the clause is correct. No,
the explanation offered in the clause seems incorrect. The explanation
says that TE must be supplied because it is a hop-by-hop header.
That's misleading because hop-by-hop headers are already handled
correctly without Connection: stuff. What it should probably say is
that TE must be supplied because 2068 compliant proxies do not know
about TE hop-by-hop header. That is, the reason for this MUST is
compatibility with earlier RFCs.

Do you see what I am getting at? An average implementor will probably
pause for a seconds and say "hmm, compliant proxies already support
hop-by-hop headers so I can ignore this MUST".

With your explanation/example, it is clear that MUST directions 
are valid. It's just that the motivation seems to be missing or is

> OK, I guess the proxy implementors of the world have some work
> left to do!  We're not going to rewrite the spec to legalize
> something bogus just because implementors aren't paying attention.

Yes, of course. This is more suitable for "known HTTP
[implementations] problems draft" and does not call for RFC changes.

Thank you,

Received on Monday, 5 August 2002 15:01:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:35 UTC