- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 05 Feb 2010 16:40:12 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Mark Nottingham <mnot@mnot.net>
Hi,
this came up while discussing Mark's Link Header draft.
For link extensions, it currently uses
link-extension = token [ "=" ( token | quoted-string ) ]
(<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-07.html#rfc.section.5>)
This is consistent with HTTP/1.1's use of parameters:
parameter = attribute "=" value
attribute = token
value = token | quoted-string
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.6>)
(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
...so 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
parameters.
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,
Julian
Received on Friday, 5 February 2010 15:40:58 UTC