Re: HTTP header representation in Fetch

On Tue, Jan 19, 2016 at 9:16 PM, Honza Bambas <hbambas@mozilla.com> wrote:
> Merging of certain headers is in Gecko prohibited for security reasons
> (injection attacks).  We explicitly hard-fail the response when there is
> more than one instance of Content-Length, Content-Disposition or Location.
> Hence merging e.g. Location is a very bad idea.

That sounds like a simplification. At least, last time I looked into
this we allowed multiple Location headers, if they contained the same
URL (after parsing). And also, if it were a "single" header with
multiple values, we did not treat it as an error. E.g., Location: a,b
at URL /relative/ causes a redirect to /relative/a,b (maybe we should
break this though, I haven't investigated if this is interoperable).
In any event, these kind of exceptions based on specific header names
makes it hard to create a generic API.


> Then we have an even wider list of headers that must not be present in a
> response more than once, see [1].  We only accept value of the first
> presence of such a header, others are silently ignored.  Only on those 3
> mentioned above we fail with an error when duplicated.
>
> Headers NOT on the list at [1] are merged to one only, so that upper layers
> see them as Header: value1, value2, ...  We definitely do this also for the
> Set-Cookie header.

Sure, with some extra magic that does not involve a comma [2]. Again,
not very generic.


> [1]
> http://hg.mozilla.org/mozilla-central/annotate/b67316254602/netwerk/protocol/http/nsHttpHeaderArray.h#l156

[2] http://hg.mozilla.org/mozilla-central/annotate/b67316254602/netwerk/protocol/http/nsHttpHeaderArray.h#l188


-- 
https://annevankesteren.nl/

Received on Wednesday, 20 January 2016 08:30:33 UTC