$Id: index.html,v 1.4 1998/01/22 21:14:45 dgaudet Exp $
This page contains all the info I know about the Navigator browser bug which results in the "POST or PUT without Content-length" errors being logged, and POSTs to fail.
Doug Salot was kind enough to send me a tcpdump with full packets of the bug in action. His bug report is on file as PR#1142, and includes the full tcpdump and some of my commentary.
I pull apart tcpdumps with a tool called tcpshow. It gives ASCII dumps of the packets in a readable form. Note that it prints a lone . for all unprintable characters, so you'll notice a . at the end of each header line for example (for the unprintable CR).
First we'll look at a successful POST from the client. Go ahead, click here and bring it up in another window, and look at it while you read my commentary.
No for a dump showing the bug. Go ahead, click here and bring it up in another window, and look at it while you read my commentary.
It looks like a cut and dry browser bug to me (I can even imagine how the code is structured and why it goes wrong). I can't find any fault in what the TCP/IP stacks are doing (except for the Windows RST issue, but that's a known stack problem). The server is behaving within the bounds of the protocols.
Notice that the server is based on Apache 1.1.3, which you can also characterize by its behaviour of flushing a packet after sending the response headers. This behaviour changed in 1.2b7 when networking performance improvements eliminated the extra flush. At any rate this session shows that it's not just a new bug -- so it is unlikely to be related to the networking performance improvements during 1.2b7.
Doug's client is "Mozilla/3.02 (WinNT; U)". We have other reports of it happening with 3.03 on NT.
In PR#1237 we have a report of it occuring with 3.02 Gold on Win95. The submitter reports that it may be caused by his installation of MSIE 4.0.
In PR#1292 we have a report of it occuring with 3.03 on Win95.
There isn't one. Ok, you can disable keep-alives (set
Off in your config), but this is a bad idea because it increases
network traffic. You can increase the length of keep-alives (set
KeepAliveTimeout), but anything beyond one minute loses
the benefits of keep-alive. Both of these should do the job, but are
unacceptable. And given that the browser is Mozilla version 3, the
most popular client out there, it's senseless to conditionally disable
keep-alive based on browser type.
If someone can think of another workaround, I'd like to hear it. (Better yet, I'd like to see code for it.)
I am unlikely to do further work on this problem because I cannot reproduce it myself. I don't use the platforms involved, and I don't have the time. But it affects so many folks that I hope some of them have the time to do more research.
What isn't known yet is if certain aspects of Apache's earlier responses on the keep-alive connection can be tweaked to avoid the bug. For example, the 257th byte bug was discovered by varying the length of a header field one byte by one byte until the bug manifested itself. Maybe something like this happens with this bug. You would have to hack up the code to work on this angle.
Here is a brief note on how you can generate useful tcpdump sessions should you find some novel new twist to the bug:
tcpdump -w dumpfile tcp port 80 and host ip.addr.of.client