- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 15 Jan 2013 15:31:22 +0100
- To: Zhong Yu <zhong.j.yu@gmail.com>
- CC: Piotr Dobrogost <p@ietf.dobrogost.net>, ietf-http-wg@w3.org
On 2013-01-15 15:28, Zhong Yu wrote: > 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) It's the only exception I'm aware of (and, btw, this hasn't changed since rfc 2068 or even earlier). Best regards, Julian
Received on Tuesday, 15 January 2013 14:31:49 UTC