can't use multiple HTTP Headers with the same name

In HTTP it allows multiple headers with the same name. However, when I went to test webapp that seems to break when IE10 sends multiple cookie headers, I can’t use httpie to test it as it only puts in the last header value in the request.

example:

$ http -v example.org Cookie:foo1=bar1 User-Agent:BAM\1.0 Cookie:foo2=bar2

Current output:

GET / HTTP/1.1
Accept: _/_
Accept-Encoding: gzip, deflate, compress
Cookie: foo2=bar2
Host: example.org
User-Agent: BAM1.0

//response omitted

Expected output:

GET / HTTP/1.1
Accept: _/_
Accept-Encoding: gzip, deflate, compress
Cookie: foo1=bar1
Cookie: foo2=bar2
Host: example.org
User-Agent: BAM1.0

Really HTTP headers should be represented as a case-insensitive MultiMap of some sort, not a Dict.

[isidentical]

What if we patched PreparedRequest.prepare_headers()? thinking

Seems like the underlying urllib3.urlopen() method (through http.client) works alright with MultiDict(), so I’d say that is also an option (we can just set the .headers = <>) after the creating the PreparedRequest (possibly not a publicly documented API to mess with, but shouldn’t be a much problem).

I’ll create another branch with an implementation of the following suggestion.

A:A A: A:B should not error, but result in A:B. The A: bit should just drop any previously specified value(s) for A.

Thanks for clarifying the actual behavior, I went with a little bit of an improvisation on this but can modify it to take this into account.

I wonder about the type mixing: maybe we should just ensure str for each item instead of throwing an exception.

I feel like bytes is the way to go instead of ensuring everything is a string. Since finalize_headers() already encode() everything to bytes, so we can do that during the insertion. But it won’t be needed if we divert to MultiDict.

Regardless of the approach we end up going for, we should make sure it plays well with --session and test-cover it.

Sure (the implementation above was just a sketch of what I was planning, not the original patch so I tested the bare minimum. actual implementation will probably include way more comprehensive tests).

This is actually a breaking change (A:A A:B will send a different request than before), so we’ll need to bump the major version.

Wouldn’t it make sense to bump the version number on the PR that is actually releasing this? But yes, this is a change of behavior (which I guess can be justified since AFAIK the previous behavior was undocumented).

Thanks for your feedback again, will let you when I have the second implementation!

[Ousret]

Something so simple yet so unsupported nowadays. Except for httpx. Also I have made something basic to help resolving issues with headers. Check out https://github.com/Ousret/kiss-headers if anyone is looking for a solution.