Re: Unknown and misplaced headers as entity headers

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?

I didn't want to imply that request and response headers need to be 
disjoint. But I think that the sets of generic headers, request+response 
headers, and entity header should be disjoint.

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

But it's the prose, not the BNF rule, doing that.

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

BR, Julian

Received on Wednesday, 27 February 2008 13:28:46 UTC