RE: Use of extension-header in entity-header

Bjoern Hoehrmann wrote:
> In RFC 2616 and the current drafts the extension-header is used only
> in the entity-header production, suggesting all headers not defined by
> it are entity headers, which I don't think is intended.

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. I'm not sure how
this interacts with the rules for Content-* header fields though.

> Perhaps it should be referenced in Request and Response as alternative to
> entity- header instead?

+1

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. For example:

    HTTP/1.1 200 OK
    Content-Length: hello

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. This also means that a single-valued header field that is duplicated
should be ignored as an unrecognized header field. It also means that any
general-, request-, or response- headers in a chunked message trailer must
be treated as (usually unrecognized) extension-headers and ignored. I think
those are all pretty surprising and unintended consequences. Almost all
implementations parse headers using the message-header production, and then
parse and interpret them based on their names, which ends up with much
different results for fields malformed header field values.

- Brian

Received on Wednesday, 20 May 2009 19:54:10 UTC