data, and sends HTTP status 500 - but then either MHD drops
the connection prematurely, or curl fails to read from it.
I have no idea what is happening.
Odd. have you tried MHD's "demo" application (which has a
POST) on W32 ever (with a browser)? This could be, after all,
an issue with curl, so this way we'd at least know that POST
works in principle...
Will try.
Ended up gdb'ing through curl.
Found the exact WinSock error code that it gets, googled it up,
came up wtih [1]. Sounds very much like our case.
[1] http://www.chilkatsoft.com/p/p_299.asp
Hmm. That's strange, because the request is not ill-formed and I
don't see why MHD would do a partial read and thus trigger this.
It also is unclear to me why the 'sleep' that we add would cause
such a winsock error. Also, if [1] is right, then Winsock would
really not implement TCP correctly, as while the data from the
sender might be "lost", the other direction of the TCP stream
should not be affected (by my reading of how TCP/IP is _supposed_
to be implemented).
You might try adding the new 'MHD_USE_EPOLL_TURBO' flag to see if
that helps; in this context, it would disable the 'shutdown' calls
on the TCP socket by MHD, which might resolve this IF winsock is
really broken.
MHD_USE_EPOLL_TURBO solves the problem.
No one ever said that WinSock is 100% TCP-compliant... :(
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10.08.2013 17:49, Christian Grothoff wrote:
On 08/10/13 15:46, LRN wrote:
Hmm. That's strange, because the request is not ill-formed and I don't
see why MHD would do a partial read and thus trigger this.
It also is unclear to me why the 'sleep' that we add would cause such a
winsock error. Also, if [1] is right, then Winsock would really not
implement TCP correctly, as while the data from the sender might be
"lost", the other direction of the TCP stream should not be affected (by
my reading of how TCP/IP is _supposed_ to be implemented).
You might try adding the new 'MHD_USE_EPOLL_TURBO' flag to see if that
helps; in this context, it would disable the 'shutdown' calls on the TCP
socket by MHD, which might resolve this IF winsock is really broken.
MHD_USE_EPOLL_TURBO solves the problem.
No one ever said that WinSock is 100% TCP-compliant... :(
Wow. Now that's insane. I guess we'll need to make that then the
default, at least for W32...
After thinking a bit, here's a possible explanation:
There's some overhead when curl connects to MHD (MHD has to accept
connection, do stuff, etc). If curl manages to fill the socket buffer on
its side right after connecting, then by the time MHD responds, curl is
ready to read the response before the connection is shut down by Winsock.
That's my theory, anyway. Difficult to say exactly what happens with
that proprietary API...