RE: Use of extension-header in entity-header

Bjoern Hoehrmann wrote:
> 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 encoded in the grammar.

It is encoded in the grammar. The names of the grammar productions do not
define the semantics. The extension-header rule could (should) be factored
out into Request, Response, and Trailer, but the resultant grammar will be
equivalent to the original.

> >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.

Specifications cannot change the syntax of the header fields defined in HTTP
1.1 in an incompatible way. If they change the syntax they need to use a
different HTTP version number.

> >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.

A conditionally-compliant implementation can, but an
unconditionally-compliant implementation can't, since it would be ignoring a
SHOULD-level requirement.

I think it makes a lot of sense to restrict the names of extension-headers
to be disjoint from at least the set of general-, request-, and response-
headers defined in the specification. Then an unconditionally-compliant
implementation could behave the way you describe.

- Brian

Received on Wednesday, 20 May 2009 22:11:33 UTC