On 12/10/2010, at 3:07 PM, john skaller wrote: > > Ok, the Felix webserver (in tools directory) is not behaving itself. > There seems to be an attempt to write on a closed connection, > after which the server just exits for unknown reason.
Well now I know: Add socket wakeup Added write filter close read fd 17file /Users/johnskaller/Desktop/Python-Docs-2.5.2/tut/tut.html Add socket wakeup Added read filter Kqueue got 1 events EVFILT_WRITE: can write (?) 146988 bytes got EV_EOF on write, socket = 16, data bytes =146988 (0?), errno/fflags?=0 posix faio wakeup PDEMUX_WRITE, writing.. posix_demuxer:socket_send posix_demuxer:socket_send wrote -1 bytes posix_demuxer: socket send failed, connection closed by client? send: Broken pipe Should have printed the error code above .. posix faio wakeup PDEMUX_WRITE, connection closed = 1 faio_req=0x100504a80, Notify 0x1005037c0 faio_req=0x100504a80, FINISHED ETHREAD CHECKING QUIT FLAG ETHREAD ABOUT TO WAIT Kqueue got 1 events EVFILT_READ: got 132 bytes coming posix faio wakeup PDEMUX_READ, reading.. posix_demuxer:socket_recv posix_demuxer:socket_recv got 132 bytes posix faio wakeup PDEMUX_READ, connection closed = 0 Add socket wakeup Added read filter ETHREAD CHECKING QUIT FLAG ETHREAD ABOUT TO WAIT Program received signal SIGPIPE, Broken pipe. 0x00007fff835ba316 in __semwait_signal () (gdb) So basically, an attempt to write on a broken connection leading to SIGPIPE killing the program .. grrr ... :) I'm not sure how to fix this, in fact I'm not sure it is POSSIBLE to fix it ;( [Other than by disabling that stupid signal :] The problem is that the connection can be closed at any time during an async write operation, or between the notification there's space to write and the actual write proceeding. <flame> IN FACT it can occur AFTER the client write is done, but before the OS has transmitted the data .. which is in fact exactly what happens when you close an asynchronous socket (all the data which is CERTAINLY just put in the buffer is lost due to a bug in POSIX). </flame> Actually I do not know WHY the connection is closed! It happens using both Firefox (loading a page with images, which are loaded in parallel), and also using two concurrent instances of curl.. what ever firefox does, curl will be doing something sane. The design of sockets (and perhaps the underlying TCP/IP protocol?) is poorly designed. IMHO ;) What the webserver does is read the GET line and then shutdown its read half of the socket. It is NOT ACCEPTABLE to read the whole message, since this opens up the webserver to a DNS attack. However it doesn't have to shutdown its reader (the client's sender). Then it sends to the client. In a robust server, this has to be time limited, again to prevent a DNS attack. Now it could be the shutdown, possibly before the whole message is read, is fooling the client into believing its request isn't going to be serviced, leading the client to shutdown *its* reader, which means the connection is then dead. It's also possible this doesn't happen on a single file request because the "random" ordering of the shutdown? Not sure, but a sequence of single requests always seems to succeed.. sometimes multiple requests also appear to succeed. Hmmm .. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
