Paul, Julian,
> I'm not sure what you're saying here. To re-iterate what I
> was *trying*
> to say...:
>
> - we should make it easy to properly handle list-typed headers
>
> - there's no *generic* way to do that
>
> - thus we should allow the API client to specify a
> micro-parser for each
> list item, and provide predefined parsers for things like etags,
> content-types etc.
This is possible and even required by the HTTP spec:
"Multiple message-header fields with the same field-name MAY be present in a
message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]. It MUST be possible to
combine the multiple header fields into one "field-name: field-value" pair,
without changing the semantics of the message, by appending each subsequent
field-value to the first, each separated by a comma. The order in which
header fields with the same field-name are received is therefore significant
to the interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded. "
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
Accept: foo/bar;ext="a,b", text/plain
To return to your example, the fact that "a,b" is a quotes string indicates
to the header parser that the comma should be ignored as a general header
separator.
Best regards,
Jerome