RE: Unknown and misplaced headers as entity headers

Julian Reschke wrote:
> > * In practice, applications cannot usefully classify an 
> > unrecognized header, and they definitely do not treat them as 
> > entity headers. Declaring them to be entity headers adds 
> > confusion with no benefit.
> 
> I agree that we have a conflict between what RFC2616 says, 
> and what many (most?) servers do. However I'm not sure there's
> a simple way to fix this.
> 
> > * The BNF for extension-header matches all other header 
> types. That means that when a client includes a 
> response-header in a request, or a server includes a 
> request-header in a response, the header is to be treated as 
> an entity header. That doesn't make any sense. 
> 
> The BNF for extension header [...]
> just defines the allowable syntax. We probably could state in 
> prose that the value must be distinct from all other header 
> names defined in the spec(s). Would that help?

As much as possible, the ABNF completely define the syntax, so that a parser can be generated from the ABNF. Also, there is no reason for response-header names and request-header names to be disjoint, and trying to force them to be disjoint creates its own real problems.

> I'm not sure how this is an improvement.
> 
> Right now we are stating that a header in a requets is either 
> a general-header, a request-header, or an entity-header. That 
> distinction is lost if we allow an additional "unclassified" type.

What problem does this cause? When an HTTP application encounters an unknown header, that header would still be a request-header, response-header, entity-header, or general-header. The only difference would be that the specification doesn't try to dictate how the application classifies it. 

> If what you're looking for is the BNF to allow new, for 
> instance, general header fields, we should extend the BNF for 
> general-header.

If you make extension-header an alternative of general-header then the BNF would match every header as a general-header. Otherwise, I would have suggested to make extension-header an alternative for every header production.

- Brian

Received on Wednesday, 27 February 2008 13:18:07 UTC