vincent.blondel@xxxxxx 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
