[xml] nanohttp: long delays & header-parsing


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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]