Re: Handling multiple headers when only one is allowed

Bil noted:
 >
 > Essentially, the first header takes precedence for Internet Explorer and
 > Safari while Firefox, Opera and Chrome use the last header.

I can't tell from the BSH ("Browser Security Handbook") that the latter case 
(use of "last header" by those UAs) was actually verified, fwiw. Are we just 
presuming that's what they do? (just kinda curious).

Perhaps another row in that BSH table is called for, e.g. "Last HTTP header of 
the same name takes precedence?", given that Michal notes that..

   "In browsers where the last header takes precedence, these are
   trivially exploitable;"

..and so it seems such behavior is worth explicitly noting.


Also, RFC2616 as well as  draft-ietf-httpbis-p1-messaging  disallow multiple 
header occurrences unless..

            ...the entire field value for that header field is
    defined as a comma-separated list [i.e., #(values)].

..though neither spec appears to define server or UA behavior if a message 
violating this requirement is received.


Michal recounts..
 >
 > we also noticed that some new specs (such as the content sniffing spec
 > that Adam Barth worked on) try to sanction precedence for individual
 > headers such as C-T - but doing so for a single header is probably
 > harmful in the sense that it creates even more discrepancies (C-D,
 > Location, Refresh, Cache-Control, etc, all have security consequences
 > too, and should behave consistently).

I groveled through the draft-ietf-httpbis-p* I-Ds and noted the 19 header 
fields listed below whose ABNF definitions appear to meet the above requirement 
  for (possibly) occurring in multiples per HTTP message.

These header fields that Michal noted in his message -- content-type, 
content-disposition, Location, and Refresh -- *are not* on that list, and so 
apparently must not occur in multiples, according to the specs.

But given that some of these header fields do appear in multiples in practice 
(for whatever reason), should UAs and servers be encouraged to do something 
other than more-or-less try to accommodate such non-conformant behavior?

=JeffH
------

HTTP Header Fields that may occur in multiples per HTTP message
===============================================================

[methodology: search for '*( "," OWS )' in specs, then inspect ABNF to confirm]

Header Field		which draft-ietf-httpbis-p*
-------------		----------------------------
Connection		part 1
Trailer
Transfer-Encoding
Upgrade
Via


Expect			part 2


Accept-Charset		part 3
Accept-Language
Content-Encoding
Content-Language


If-Match		part 4
If-None-Match


Accept-Ranges		part 5


Cache-Control		part 6
Pragma
Vary
Warning


Proxy-Authenticate	part 7
WWW-Authenticate


---
end

Received on Thursday, 17 December 2009 21:10:18 UTC