- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 15 Jan 2013 08:28:49 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Piotr Dobrogost <p@ietf.dobrogost.net>, ietf-http-wg@w3.org
On Tue, Jan 15, 2013 at 6:21 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2013-01-15 12:47, Piotr Dobrogost wrote: >> >> To summarize, from the point of view of http client library (see >> https://github.com/kennethreitz/requests/issues/741): >> >> - The safe approach is to not merge any header fields with the same field >> name. > > > Yes. > > >> - If merging, merge only those fields which are known to be safe to >> merge ie. those, which can be parsed after merging. Also, if the top >> most production in BNF specyfing field's value is #(values) it does >> NOT mean the field is safe for merging although this seems to be >> implied by the statement in the spec starting with "Multiple header >> fields with the same field name MUST NOT be sent (...)" > > > If a spec uses the list production but then doesn't allow proper parsing > then that spec is buggy (such as Set-Cookie). It's good to know whether Set-Cookie is the only exception among well-known headers existed before rfc2616? (Any headers introduced after rfc2616 should follow the rule; no slack for them) Zhong Yu
Received on Tuesday, 15 January 2013 14:29:16 UTC