On 01/06/2008 02:20 AM, Nick Kew wrote: > On Sat, 05 Jan 2008 20:28:33 +0100 > Ruediger Pluem <[EMAIL PROTECTED]> wrote: > >> >> On 01/05/2008 07:04 PM, Nick Kew wrote: >>> On Sat, 05 Jan 2008 12:38:58 +0100 >>> Ruediger Pluem <[EMAIL PROTECTED]> wrote: >>> >>>> Ok. Can you setup a tcpdump between proxy and server and between >>>> client and proxy? I guess the network traces would be very helpful >>>> in finding out where things are starting to get wrong. >>> One testcase with its tcpdump at >>> http://people.apache.org/~niq/2.2.7/ >> Thanks for this, but I think this is not sufficient: >> >> 1. It seems the dump is incomplete as I cannot see a 0 chunk at the >> end. 2. I would prefer the binary dump as it offers more >> possibilities to analyse it with wireshark. >> >> Sorry for being that demanding :-) > > Do you mean as in tcpdump -x? I've uploaded a pair of dumps > (one of client-proxy, the other of proxy-server) at the same > location.
Thanks for that. I think I know what happens: 1. Have a look at the data send to the client. It ends with nesyp\r (see packets 7 and 8 of client.dump) 2. If we have a look at packet 7 of server.dump it ends on 1\r\n n \r\n 1\r\n e \r\n 1\r\n s \r\n 1\r\n y \r\n 1\r\n p\r\n 1 Note that the last byte of this packet is no complete chunk size line. The next packet from the backend is packet 9 which arrives 200 milliseconds later. The data payload starts with \r\n t \r\n What happens in the code? In line 333 of http_filters.c we read the '1' from packet 7. We read this in non blocking mode as we were able to read all previous bytes from this packet non blocking. Keep in mind that we call ap_get_brigade in line 1623 of mod_proxy_http.c for every single character of the response from the backend as we read one complete chunk at most in one single ap_get_brigade call. As we are in non blocking mode and the \r\n only arrives with next packet 200 milliseconds later ap_get_brigade does not return a complete line to us but only 1 and APR_SUCCESS. But we think we have read the full chunk size line and continue our operation accordingly. It doesn't matter if we have a failed (APR_EAGAIN) non blocking read or not in between, our next successful read of *1 byte chunk data* is *\r* that was originally part of the chunk size line. After that we try to get the linefeed after the chunk. And it is there. It is the \n of the chunk size line. Next we expect a new chunk size line so we read byte 3 till 5 of packet 9: t\r\n t is no valid hex character, but get_chunk_size silently ignores this and returns *0* which means that we are complete. So my patch should address this as it insists to read the complete line before we process it. So these kinds of splits between TCP packets does not harm the code any longer in non blocking mode. Regards Rüdiger
