RE: Unknown and misplaced headers as entity headers

Julian Reschke wrote:
> Brian Smith wrote:
> > 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.
> 
> Well, that's probably not possible to do in ABNF. How would 
> you write a rule that excludes specific names?

RFC 3986 uses a "first-match-wins" disambiguation rule. If the input matches more than one alternative, then it is matched by the first matching alternative. So, in the BNF I gave, using a similar rule, a header in a request would only match extension-header if it did not match general-header, request-header, or entity-header.

> 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. 
> 
> But it's the prose, not the BNF rule, doing that.

Right, but you don't have to know the classification of an extension-header to parse 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.
> 
> Well, yes. If we say that in specific cases new general 
> headers *can* be introduced, the BNF rule should reflect that.
>
> And as there is no way to decide the nature of an unknown 
> header, the BNF is not going to help here.

What I meant was, using a "first-match-wins" rule, every header, including request/response/entity-headers, would get parsed as a general header.

If the ABNF is not required to be unambiguous, then I would put extension-header in each of the general-header, request-header, response-header, and entity-header productions, to better match the semantics, since the semantics are ambiguous.

- Brian

Received on Wednesday, 27 February 2008 13:48:51 UTC