default qualities in multi-line accept headers

[Eric Prud'hommeaux <er...@w3.org>]

lynx sends multiple Accept headers like:

 Accept: text/html, text/plain, application/applefile, application/x-metamail-patch, sun-deskset-message, mail-file, default, postscript-file, audio-file, x-sun-attachment, text/enriched, text/richtext, application/andrew-inset, x-be2
 Accept: application/postscript, message/external-body, message/partial, application/pgp, application/pgp, video/mpeg, video/*, image/*, audio/mod, text/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png, image/x-xbitmap, image/x-xbm
 Accept: image/gif, application/postscript, */*;q=0.01

This means that text/html, text/plain and everything on the first
line, as well as those on the second line, assume the default q of
1.0.

The CGI script gets all those headers mushed into a single
$ENV{'HTTP_ACCEPT'} like:

 text/html, text/plain, application/applefile, application/x-metamail-patch, sun-deskset-message, mail-file, default, postscript-file, audio-file, x-sun-attachment, text/enriched, text/richtext, application/andrew-inset, x-be2, application/postscript, message/external-body, message/partial, application/pgp, application/pgp, video/mpeg, video/*, image/*, audio/mod, text/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png, image/x-xbitmap, image/x-xbm, image/gif, application/postscript, */*;q=0.01

This is interpreted as everything is at q=0.01. 

Perhaps lynx is at fault for splitting lines that are not strictly
concatonatable comma-separated lists. From rfc2616#4.2:

   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.

(#14.1 describes how unqualified Accept fields are assumed to be at
relative quality 1.0). One solution to this is to re-write the Accept
headers with the proper qualities before stuffing them into the
HTTP_ACCEPT environment. What do you all think?

-- 
-eric

(eric@w3.org)