(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
