Re: allowable characters in token as used in parameter ABNF

Mark Nottingham wrote:
> Speaking personally --
> 
> I'm torn here. On one hand, I'd very much like to see best practice promoted here, because the wild-west situation of HTTP header parsing is one of the things I really dislike, and suspect causes a lot of problems.
> 
> OTOH, we don't have any implementers stepping up and saying that they're eager, and in this situation it may be too easy to specify the wrong thing.
> 
> AIUI the most liberal form of xtoken would be 1*VCHAR without DQUOTE, "," or ";". Correct?

That will make it:

"!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / 
"/" / DIGIT / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA / "[" / "\" / 
"]" / "^" / "_" / "`" / "{" / "|" / "}" / "~"

which includes the following non-token characters:

"(" / ")" / "/" / ":" / "<" / "=" / ">" / "?" / "@" / "[" / "\" / "]" / 
"{" / "}"

"(" and ")" *might* become a problem in headers that allow comments.

"\" might be confused with the escape character in quoted strings and 
comments.

Other than that, I don't see a problem.

> If we can get agreement to that, I think we could document that as the construct for link-extension in the link draft, and perhaps recommend it in section 4 of Julian's draft when talking about how to accommodate extensibility. 

Sounds good.

> Beyond that, we have a bit more time to figure out if it's useful in httpbis as well.
> 
> Thoughts?

I think for httpbis it will be valuable if we add a section with 
guidance on defining new header fields (which we should). Not sure 
whether we'd want to change any of the existing ABNF...

Best regards, Julian

Received on Tuesday, 9 February 2010 13:34:54 UTC