package:http abstracts request headers as a Map<string, string>; that does not work for repeating headers

[DartBot]

This issue was originally filed by [email protected]

---

Package http represents request headers as a Map<string, string>, both in requests as well as in responses. That does not work for repeating headers, In that case one needs to fold them into a single string. Which is not always practical or possible.

What steps will reproduce the problem?

The most problematic header is Set-Cookie since the concatenation of multiple cookies into one string is tricky to parse.

Please provide any additional information below.

Some browsers and libraries e.g. http.cookies in Python can deal with folded Set-Cookie headers.

RFC 6265 says "don't do that" (section 3)

[anders-sandholm]

Added Area-Pkg, Pkg-Http, Triaged labels.

[nex3]

The plan here for both http and shelf is to provide a way to access headers that preserves repetition for cases like this. Something like a multiHeaders hash or a getMultiHeader method would work here. There will probably also be a more specialized way of accessing parsed cookies as well (issue #19005).

Unfortunately I probably won't have time to work on this for a while yet. If you want to take a stab, I can certainly review patches!

---

Added PatchesWelcome label.

[DartBot]

This comment was originally written by [email protected]

---

What about copying the API dart:io has?

dart:io.HttpClientResponse:

• List<Cookie> get cookies
• HttpHeaders get headers

dart:io.HttpHeaders seems quite a high-level general class. I would've preferred if it conformed to Map<String, List<String>> interface, though then there would be the problem of naming the set() and add() methods. The Map.addAll would actually mean calling set() for each value, not add())… So it might be better as it is.

dart.html does headers wrong as well, on HttpRequest (which stands for both the request and the response) they have
 - String getResponseHeader(String header)
 - Map<String, String> get responseHeaders
 - String getAllResponseHeaders()

but it does not matter much because the browser leaves out set-cookie headers http://www.w3.org/TR/XMLHttpRequest/#the-getallresponseheaders%28%29-method .

Anyways, I'd prefer having the api dart.io has everywhere, over inventing yet another one. There are three different APIs already: dart.io.httpclient, http, dart.html.httprequest and there is also chrome.cookies in package:chrome (which encapsulates what different languages would call a cookie jar). Then there are various related cookie and session packages on Pub… Angular.dart has their own cookie classes…

[nex3]

The dart:io style of having an idiosyncratic Map-like object is much less usable than having an actual Map in terms of both interoperability and conceptual overhead. It also considers headers to be multi-valued by default, which makes the much-more-common case of working with single-valued headers unduly difficult.

There's certainly room to do better in the package:http API than what it does now, including borrowing some ideas from dart:io like providing access to parsed versions of well-known headers. But providing a better API is the reason this package exists, and this is a case where it can do so.

[DartBot]

This issue has been moved to dart-lang/http#24.