- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 15 Jan 2013 17:12:51 -0800
- To: Nico Williams <nico@cryptonector.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Karl Dubost <karld@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Piotr Dobrogost <p@ietf.dobrogost.net>, ietf-http-wg@w3.org
On Jan 15, 2013, at 4:07 PM, Nico Williams wrote: > On Tue, Jan 15, 2013 at 6:01 PM, Mark Nottingham <mnot@mnot.net> wrote: >> On 16/01/2013, at 10:57 AM, Nico Williams <nico@cryptonector.com> wrote: >>> No. I'm saying that it's OK for apps to do that but not any other >>> entities (middleboxes), mostly because middleboxes can't possibly know >>> about headers that hadn't been registered when they were implemented. >> >> OK. Is this an actual problem you've encountered? >> >> I'm fine with adding some clarifying text if it helps implementers, but I haven't seen this confusing any middlebox vendors; they tend to leave the bits alone... > > I noticed Poul's and someone else's replies that in their middlebox > implementations they concluded that it's never safe to merge headers. > If that's the case (and I do think it follows from the facts that it > is the case) then we should say so rather than leave each implementor > to figure this out on their own. The requirement is on generating headers, so it does not concern middlebox vendors other than for the fields that they add to a message. Apache httpd merges header fields as they are read from the network. So does any correctly written client that reads internet message format (like all of the common MIME and libwww libraries). If you want to interoperate on the Web, field generators must obey that requirement. ....Roy
Received on Wednesday, 16 January 2013 01:13:17 UTC