Re: Use of extension-header in entity-header

* Brian Smith wrote:
>Part 1 and Part 2 both explicitly states that all unrecognized header fields
>are to be treated as entity headers. However, Part 6 says "Unrecognized
>header fields SHOULD be ignored by the recipient and MUST be forwarded by
>transparent proxies." I think Part 6 is right the other statements regarding
>unrecognized header as entity header fields should removed.

How implementations treat unrecognized headers is a separate concern; my
issue is with other specifications adding new headers that aren't entity
headers. They would require an extension point that's not currently en-
coded in the grammar.

>But, even with that done, there is a serious problem with extension-header
>in the grammar. If the value of a HTTPbis-defined header field is malformed
>in a message, then according to the grammar, the malformed header field is
>to be treated as an extension header.

That seems okay, as implementations would be unable to tell whether it
is indeed malformed, or just conforms to some definition that postdates
the implementation, in other words, some kind of extension.

>According to the grammar, we are supposed to parse this as a
>syntactically-valid response with a "Content-Length" extension header.
>Combined with the statement above, we should ignore this unrecognized
>Content-Length extension-header field; that is, we shouldn't report an
>error.

That is not the implication. An implementation is always free to note
that it has encountered content that it does not fully support, or re-
fuse to process a message for reasons of security if it detects what
seems like a malformed header.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 20 May 2009 20:48:26 UTC