Re: Unknown and misplaced headers as entity headers

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

Interesting, thanks for mentioning this.

However, I'm not sure we want to apply that trick here. How would it 
affect code generated based on the ABNF?

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

Well, you don't need anything of this to parse. Just a general rule 
specifying the syntax for headers.

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

Yes. We wouldn't want that.

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

I guess the question here is: given the constraints of both ABNF and the 
header extensibility, what exactly is the goal of the ABNF in the spec?

BR, Julian

Received on Wednesday, 27 February 2008 14:06:40 UTC