Re: [squid-users] any work arounds for bug 2176

vincent.blondel_at_ing.be wrote:
>
> On Fri, Jan 01, 2010 at 12:36:12AM +1300, Amos Jeffries wrote:
>>> I've taken a good look at the trace files on this. It's clear that
> the
>>> client is in fact not sending the whole initial POST.
>>>
>>> What I see happening is that the server early response gets relayed
> by
>>> Squid and if the connection is not aborted Squid receives a small
>>> further portion of data from the client before it abruptly stops and
>>> starts sending the re-send POST with auth details.
>>>
>>> Since the client has indicated a certain length X of data then only
>>> sends N bytes the start of second request is lost and the server
>>> complains that some random bytes mid-way down the repeat POST are an
>>> invalid request method "verb".
>>>
>> Ah, ok. I missed that :)
>>
>>> To get this going we are going to have to add to the patch a bit to
> make
>>> Squid delay the relayed reply until the initial POST is fully
> received.
>> Do you need help with this? I don't know the squid code but should be
>> able to muddle through if you can give a pointer.
>>
>>> PS: This has pushed Squid very, very close to the wanted behavior for
>
>>> Expect-100 HTTP/1.1 requests/replies. Thanks guys.
>>>
>> Thanks for looking in to this.
>
>
> can somebody say me if there is already a new patch for this bug ??
>

You will have to ask the IIS authors about that. Or the browser authors
about why its not sending proper auth on a new connection when it has
been told it needs to. It's their software that is actually broken.

We are just working on a hack that might be able to make Squid cope with
the problem. And no, the hack we have so far only shifts the boundary
out a few KB from where it started.

PS. you really want to disable that read-receipt request on mailing list
messages. You could get thousands of replies.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
   Current Beta Squid 3.1.0.15