W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: [#95] Multiple Content-Lengths

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>
Message-ID: <20110309225829.GD29190@1wt.eu>
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

> 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.

Received on Wednesday, 9 March 2011 22:59:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC