Hi,
I'm not sure, but I somehow have the impression that there are subtle
differences in winsock which confuse Neon :-)
I'm experiencing something similiar to my original report when trying
to access
http://mediacenter.gmx.net/
(works fine via cadaver / MacOS, so it seems to be Windows related).
In this case I can't even authenticate.
The sequence goes like this:
ne_begin_request => NE_OK
ne_get_status => 401
ne_response_header_iterate
=> content-length: 7554 (server returns some HTML, uncompressed)
then
ne_discard_response
ne_read_response_block(..., 8192)
read_response_block => readlen=1312
gz_reader() // switches to PASSTHROUGH
own-reader(..., 1312)
ne_read_response_block(..., 8192)
read_response_block
=> R_CLENGTH (remain=6242) => willread = 6242
and here it fails:
ne_sock_read(6242)
recv(..., 6242)
=> ret = -1
errnum = 10054 (WASECONNRESET)
=>
NE_ERROR as a result of ne_discard_response
First question: should libneon be a bit more tolerant with content
returned for errors? It got a full header for the 401 and could
continue with authentication after a connection shutdown?
Anyways. Real issue. OK, what happens on the server is probably this
sequence:
1. receive request
2. send 1st TCP block containing HTTP header and some content
(1312 bytes)
3. send 2nd TCP block containing rest of content (6242 bytes)
4. shutdown connection
Wild theory: Windows consumes 2). It _might_ have 3) in its socket
buffers, but it also get 4) out-of-band while Neon did not yet call
the 2nd recv().
So maybe the difference between winsock and Unix sock is that winsock
recv() will deliver the WASECONNRESET immediatly even if there is
content pending? While Unix sock will deliver the content, and only
deliver the WASECONNRESET state on the next call to recv()?
I guess that would explain many of the other issues I've seen as well.
Thanks,
Helge