allowable characters in token as used in parameter ABNF


this came up while discussing Mark's Link Header draft.

For link extensions, it currently uses

   link-extension    = token [ "=" ( token | quoted-string ) ]


This is consistent with HTTP/1.1's use of parameters:

   parameter               = attribute "=" value
   attribute               = token
   value                   = token | quoted-string


(Reminder: this is the old RFC2616 ABNF style, allowing LWS between 
tokens and words etc)

However, for the (non-extended) parameter "type", the draft says:

   "type" "=" type-name "/" subtype-name it uses a syntax that wouldn't be allowed for link-extensions ("/" 
is not allowed in tokens.

Testing with the two UAs that do something with the Link header (Opera 
and FF) show that they happily accept both quoted and unquoted type 

So minimally,

   "type" "=" DQUOT type-name "/" subtype-name DQUOT

should be allowed as well.

However, special-casing the syntax for predefined parameters feels lame 
-- it would be good if you could use a generic parser to get all components.

So one way out of this would be to require that *all* parameters follow 
the pattern

   parameter               = attribute "=" value
   attribute               = token
   value                   = token | quoted-string

 From a purity point of view, that probably would be best. However, we 
have evidence (see above) that some implementations do not require 
quoted-string for certain characters that *are* forbidden in token.

Of course this could be addressed by saying "be lenient in what you 
accept", and be done with it.

Another approach that we'd like to discuss is to widen the set of 
characters that are allowed in unquoted parameter values, such as

   parameter               = attribute "=" value
   attribute               = token
   value                   = xtoken | quoted-string

and make xtoken extend token, also allowing certain harmless characters, 
such as "/".

If we do this, we'd really like to do this consistently in both 
draft-nottingham-http-link-header and draft-reschke-rfc2231-in-http, and 
potentially even define it in HTTPbis (maybe just as a recommended 
syntax component for new header fields).

Feedback appreciated,


Received on Friday, 5 February 2010 15:40:58 UTC