RE: Parsing headers, was: Abstract from HTTP <was> Re: Welcome to JSR 311

From: Jerome Louvel <>
Date: Tue, 10 Apr 2007 15:34:34 +0200

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

        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

Best regards,