Re: Use of extension-header in entity-header

Brian Smith wrote:
> 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.

s/Part 6/Part 3/.

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

As far as I can tell, this is a left-over from RFC2616 that we're 
planning to address later on. The ABNF as currently written references 
all the micro-ABNFs for the individual headers (well, those defined in 
RFC2616).

What it should do is just define the generic parsing of header lines 
(what is a legal line? If it is legal, what is the header name and what 
is the field value?), and then refer to each "value" ABNF for the 
individual headers (that's why, in draft-05, we already split the header 
ABNFs into "Fieldname" and "Fieldname-v").

BR, Julian

Received on Thursday, 21 May 2009 15:23:50 UTC