- From: Brian Smith <brian@briansmith.org>
- Date: Thu, 21 May 2009 13:00:13 -0500
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Brian Smith'" <brian@briansmith.org>
- Cc: "'Bjoern Hoehrmann'" <derhoermi@gmx.net>, <ietf-http-wg@w3.org>
Julian Reschke wrote: > 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"). That makes a lot of sense. It means there won't be a complete ABNF grammar for HTTP messages, but it does mean that the specification will match what implementations actually do. (See more comments below.) Julian Reschke 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. > > Perhaps it should be referenced in Request and Response as > > alternative to entity-header instead? > > I think this is on purpose; Roy has pointed out frequently that > HTTP/1.1 doesn't have an extension point for this. > > Now, should we / can we fix this? Dunno. If the change you described above is made, then the grammar won't have separate general-/response-/request-/entity-/extension- productions, so it won't matter. - Brian
Received on Thursday, 21 May 2009 18:00:53 UTC