[Catalyst-dev] HTTP engine closing socket on header failure

[Andy Grundman]

On Apr 4, 2008, at 3:22 PM, Ton Voon wrote:
>
> On 4 Apr 2008, at 17:08, Andy Grundman wrote:
>>
>> On Apr 3, 2008, at 5:49 PM, Ton Voon wrote:
>>> Hi!
>>>
>>> We hit a problem with the HTTP development engine where a  
>>> connection would come in without any headers and the remote socket  
>>> wasn't being closed correctly.
>>>
>>> This patch to Catalyst::Engine::HTTP closes the Remote connection  
>>> and also prints debug statements around the sysread.
>>
>> Thanks.  You're right that STDIN is set to non-blocking before  
>> _read_headers is called the second time, so it needs to support non- 
>> blocking mode.
>>
>> Your patch looks sane, I've committed a slightly modified version.   
>> A test case would be nice but I realize it's a bit hard in this  
>> case.  I tested manually and saw the connection bug with the old  
>> code, and the patch definitely fixes it.
>
>
> Great - I'm glad you found it useful.
>
> Actually, we did a bit more digging and found another limitation.  
> The symptoms we were seeing was that the dev server was hanging on a  
> read(), which is at the sysread() call in _read_headers. We don't  
> understand why this happens, but since the _read_headers is done by  
> the main myapp_server.pl process before a fork, this means that all  
> subsequent connections hang until the sysread() times out (or the  
> connection is closed - not sure which).
>
> We've amended the code in C::E::HTTP within the accept() loop so  
> that it forks immediately, instead of trying to read the headers  
> first. This means the connection that was causing the problem (which  
> is pretty random, about 5 times a day) hangs, but all other requests  
> work fine thus isolating the issue.
>
> The downside to this is that the RESTART method is not available  
> anymore. Would you be interested in this patch?
>
> Ton

Hmm, I don't want to break RESTART though.

You may be interested in a new engine I'm about to release hopefully  
later today that implements pre-forking and scales a lot better than  
the built-in HTTP engine.