[xml] nanohttp: long delays & header-parsing

[Coren <einprogress e201 hadiko de>]

 Hello,

I use nanohttp to communicate some xml documents with a server.
I send a request, the server calculates the result and sends it back.
So far, so good... in theory.
In practice I stumbled over the following things making me a bit 
unhappy... :>
Bug: nanohttp insists on getting the headers in less than 30 seconds.
If the server takes longer than 30 seconds to get his job done, nanohttp 
leaves the section between lines 1397 and 1413, which means, the head 
ends later up at the top of the data stream that I get.

My first idea was to split state XML_NANO_HTTP_READ into
XML_NANO_HTTP_READ_HEAD and XML_NANO_HTTP_READ_DATA, and defer the 
parsing until the proper End-Of-Header mark (= empty line) is found, 
i.e. set state to XML_NANO_HTTP_READ_HEAD and in xmlNanoHTTPRecv parse 
the received data until the EOH is found, then push it to 
xmlNanoHTTPScanAnswer, change state and from there allow data to come 
thru to the user.

But this does interfere with the redirect-code, that depends on the 
header being parsed ahead of it. Duh! And moving that to xmlNanoHTTPRecv 
 just doesn't seem right...

Unexpected features: 1. Linux: nanohttp yields "error : Operation in 
progress" instead of "Connection refused" when there is no server 
running. I have no idea, where this text comes from... connect in 940 
most probably gives EINPROGRESS. But there is no perror call after that 
which could put this out?

   2. Windows: I guess the non-blocking part works not right, as it 
takes 30 seconds (i.e. one timeout) for nanohttp to find out that there 
is no server running... Or is that the regular behaviour for sockets 
under Windows? I.e. does select not work at all as expected?

TIA,

  Coren