Re: Issues addressed in the -10 and -11 drafts

Hi Mark,

On Tue, Sep 14, 2010 at 03:31:14PM +1000, Mark Nottingham wrote:
> On 02/09/2010, at 4:00 PM, Willy Tarreau wrote:
> >> #95 - Handling multiple Content-Length headers (-11)
> > 
> > I reported a few cases of duplicated content-lengths I already observed
> > and the fact that I decided to only allow multiple content-lengths if
> > they are all exactly the same.
> 
> How common is this in your experience? 

Very rare, I would say that I might have observed them 2-3 times in
10 years but I was not specifically looking at that, so it might be
slightly more common. It was always caused by a poorly written
application somewhere. But you know how it works : "my application
worked before you plugged your system there, so your system is buggy
and must be fixed". It is even more complex when you install your
system at a customer's and it's one of their customers which
experiences the issue (I've had that several times with forbidden
characters in header names).

> > You said that for this specific case this
> > was probably acceptable. Do you think relaxing the rule for this specific
> > case merits a a small add-on to the spec or should we simply enfore the
> > test and wait for code responsible for duplication to get fixed when
> > facing the errors (after all, since the content-length is not defined as
> > a comma-separated list, it should never appear more than once, but you
> > know the difference between what we say and what we observe) ?
> 
> 
> I think there are two concerns here:
>   1) making the spec more complex
>   2) making code implementing the spec more complex
> 
> Is it going to cause your implementation problems to refuse messages with two matching content-length headers?

No, it's even easier, I can remove a test in the code ! But I
suspect that I'll have to relax the check again in a few months
to a few years because of the effect mentionned above. Maybe we
could add a single sentence at the end of point 3 of 3.3 :

 "An implementation MAY accept exact duplicates of valid Content-Length
  header fields as a single one, though this practice is discouraged".

At least it will suggest how to handle the case for implementations
that have no other choice when facing the problem. The fact that
several implementations already make a special case of this indicates
to me that the need was encountered at least once.

Regards,
Willy

Received on Tuesday, 14 September 2010 05:50:42 UTC