- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 9 Mar 2011 23:58:29 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Mar 09, 2011 at 11:21:46PM +0100, Julian Reschke wrote: > On 09.03.2011 19:04, Mark Nottingham wrote: > >I've scheduled this for -13. > > > ><http://trac.tools.ietf.org/wg/httpbis/trac/ticket/95#comment:20> > > > > > >On 20/02/2011, at 11:12 PM, Mark Nottingham wrote: > > > >>So, I propose: > >> > >>* adding text that allows duplicates explicitly, and > >> > >>* upgrading the SHOULD to a MUST in this requirement: > >> > >> If this is a response message received by a user-agent, it SHOULD be > >> treated > >> as an error by discarding the message and closing the connection. > > ...clarifying: you say "adding text that allows duplicates > explicitly"... that could be read to REQUIRE recipients to accept those > duplicates -- are we really going to declare recipients that do not do > that to be non-compliant? That would be a big mess, because the real issue comes from the non-compliant servers which emit them twice. I'd rather use a MAY here. > If we do, we *probably* need to adjust the header field ABNF (because > "x, x" doesn't parse), which I'd rather do not... That makes me realize that content-length is not the only header in this case. It's probably one of the most dangerous ones when the differing content-lengths are observed though. But I've already seen buggy apps or app servers returning a bunch of duplicate headers. So maybe instead of writing something explicit for content-length, we could suggest something along those lines (I don't like that much but I'm trying to help find a pragmatic solution) : Headers which are not defined as coma-separated values and which appear multiple times MAY be folded into a single one by the recipient only if they all have the exact same value. Similarly, a header which does not support comas and which is received with multiple exactly identical values delimited by comas MAY be folded into one such single value. All non-matching situations MUST be rejected. Examples : Content-length: 100 Content-length: 100, 100 1) reduce individual header lines to single values : Content-length: 100 Content-length: 100 2) reduce repetitive occurrences to a single line : Content-length: 100 Non-working example : Content-length: 100 Content-length: 100, 102 per-line reduction not possible on the second one, and both header lines don't match. I've seen those duplicates often with Content-type for instance. Note that every time I observed a duplicate, there were really two header lines, so probably that most components capable of folding them sometimes also take care of cleaning the mess. Thus maybe we could just amend the folding paragraph with a duplicate removal suggestion and still not allow comas in Content-Length. That should cover most situations I have observed without opening a dangerous can of worms. Regards, Willy
Received on Wednesday, 9 March 2011 22:59:09 UTC