begin_request fails with connection was closed by server

Helge Heß me at
Wed Aug 26 09:50:56 EDT 2009


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

(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
     => content-length: 7554  (server returns some HTML, uncompressed)

     ne_read_response_block(..., 8192)
       read_response_block => readlen=1312
       gz_reader() // switches to PASSTHROUGH
         own-reader(..., 1312)
     ne_read_response_block(..., 8192)
         => R_CLENGTH (remain=6242) => willread = 6242
and here it fails:
           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  
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.


More information about the neon mailing list