Re: Assert used in Flood and its triggering under Sun Solaris

[Justin Erenkrantz <je...@ics.uci.edu>]

--On Monday, April 28, 2003 07:22:10 -0400 Norman Tuttle 
<nt...@photon.poly.edu> wrote:

> (1) What is the purpose of the assert here, and why might it be failing
> specifically on a Solaris system?, and

IIRC, it is meant to assert an HTTP protocol violation wrt chunking.  The 
assert at flood_socket_keepalive.c:467 looks like it is trying to skip over 
the CRLF after the chunk size.

My guess is that the assert could be triggered if the chunk line wasn't 
fully available.  Yet, if those characters weren't read, then 
keepalive_read_chunk_size is going to have problems as well (but won't 
trigger an assert - it'd return 0 for the chunk length - which is wrong). 
So, at that point, we have no idea how much we should be reading in the 
response, but we *did* read something in the response after the headers - 
note all of the checks on the size (see line 440).

Note that a quick hack would probably be to try to read more from the 
socket at this point in a blocking (non-blocking *might* work, but is 
suspect) read - in the hopes that the rest of the chunk line is available.

Taking a look at the first few characters of new_resp->chunk should show 
this.  At that point, new_resp->chunk should be something like '5f\r\n' 
where 5f is the chunk length in hex.  I bet you've got a partial chunk size 
without the trailing \r\n or something equally screwy.

And, if you don't have '5f\r\n' but rather content, then you've got a 
broken server that is indicating chunking without really chunking the 
response.  That's illegal - the assert was meant for those cases rather 
than the partial chunk line.

> (2) What would be a more graceful way of reporting this error rather than
> aborting the system with a core dump? I have an exception reporting
> mechanism in place, and just want to understand how the system should
> recover in this case. It seems that the code is highly coupled with
> notions of chunked encoding.

The whole protocol logic needs to be revamped.  Serf's protocol logic is 
much cleaner than flood's (partly because the flood protocol code is 
fundamentally flawed).  But, that requires someone with time to get flood 
to use serf instead.  The chunking code and SSL logic is *way* cleaner 
since we rely upon filters...

As to the explanation as to why Solaris shows this while Win32 doesn't is 
probably because of the underlying socket buffers.  Win32 may be returning 
when it has that \r\n, while Solaris is breaking first.  -- justin