- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 16 Jan 2013 22:27:37 +1300
- To: ietf-http-wg@w3.org
On 16/01/2013 2:29 p.m., Zhong Yu wrote: > On Tue, Jan 15, 2013 at 7:02 PM, Nico Williams <nico@cryptonector.com> wrote: >> On Tue, Jan 15, 2013 at 6:53 PM, Julian Reschke <julian.reschke@gmx.de> wrote: >>> On 2013-01-16 00:38, Piotr Dobrogost wrote: >>>> I guess what Nico had in mind is if this subject could be clarified in >>>> 2.0 so that we won't have problems we have now in the future. >>> >>> What problem, exactly? >>> >>> Given a valid message, you can combine header fields as specified in the >>> spec. But you don't have to. >> You shouldn't if you're a middlebox. >> > On the server side, it is a good idea to merge headers. There's no > point for a server framework to return multiple values for one header > name - application will have to merge them anyway before parsing. > (Java Servlet for example does not merge headers; it's a source of > bug; fortunately clients usually don't split headers) > > On the client side, it's probably the same story (except Set-Cookie) In the middle it is simply difficult to merge correctly without adding further mistakes. However for those willing to go to the effort to optimize the headers merging can be very useful tool for reducing bytes. A warning that many senders still generate corrupted headers may be useful but I see no reason to make it a "should not" as these problems will face a compliant client as much as any middle box. Amos
Received on Wednesday, 16 January 2013 09:28:15 UTC