ext Daniel Stenberg wrote:
> On Fri, 2 May 2008, Jari Urpalainen wrote:
>
>> Sorry Daniel, not a test (at least yet) but attached the second
>> proposal to fix the bug. So I've been studying the case (and the
>> code) more thoroughly and have finally located the culprit (and yes
>> it is indeed simple once you really get it). So this is about a race
>> condition between writing and reading. So when you have a body and
>> you write it to the server within a "digest session" and the server
>> declines the request by a 401 response (stale session), the keepon
>> flag will stay with the KEEP_WRITE bit set if the read stream is not
>> read again second time (small body which fits into a single
>> writebuffer) before interpreting the 401 response.
>
> Given this description, it gives me the feeling you may in fact suffer
> from effects of the bug we're working on in this bug report:
>
> http://sourceforge.net/tracker/?group_id=976&atid=100976
>
> Does the "rewind-2.patch" patch in there make any difference to you?
>
it's definitely about ~ similar issue, but it doesn't work in my case,
since rewindaftersend will not be set with that patch.

If you add yet another condition test into perhapsrewind:

  else if (conn->data->state.digest.stale ||
       conn->data->state.proxydigest.stale)
    conn->bits.rewindaftersend = TRUE;

it will also work in this particular digest case. That being said, i'd
personally prefer to avoid the zero byte write callback altogether ;-)
but it's not my call...

br, jari
Received on 2008-05-05