Apache and Tiger
I’ve been taking a little vacation from blogging. We will return to your regularly-scheduled programming soon.
However, I did want to bring up one very serious bug that may be affecting some of my visitors.
In the comment thread to my WebDAV post, Andreas Amann points out that there seems to be a serious incompatibility between MacOSX 10.4 and Apache 2.0.x.
I had not noticed any such problem exchanging 200 KB PDF files under WebDAV. The reason — as I will explain below — is that the Apple Finder WebDAV client is clever enough to hide the problem from me.
The problem seems to be that, while the server thinks it’s sent the entire file, the client receives only the first 70 KB or so, and then sits there till the connection times out. Here’s what happens when you retrieve the front page of this blog:
% curl -O http://golem.ph.utexas.edu/~distler/blog/index.shtml % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 77636 0 77636 0 0 4915 0 --:--:-- 0:00:15 --:--:-- 0 curl: (18) transfer closed with outstanding read data remaining
Of the 15 seconds that elapsed, the first 5 were spent retrieving data. During the remaining 10 seconds, the client didn’t get another byte.
On the other hand, the server thinks it sent the whole file successfully:
adsl-69-109-79-66.dsl.snfc21.pacbell.net - - [15/May/2005:12:34:21 -0500] "GET /~distler/blog/index.shtml HTTP/1.1" 200 181988 "-" "curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7b zlib/1.2.2"
(Note the 200 “Success” Status code and the correct length of the page.)
The reason you, dear reader, have not encountered this problem is that your browser accepts compressed content
% curl --compressed -O http://golem.ph.utexas.edu/~distler/blog/index.shtml % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 49008 100 49008 0 0 32303 0 0:00:01 0:00:01 --:--:-- 43057
When sent compressed, the page is well shorter than the size at which MacOSX 10.4 and Apache 2.0.x crap out.
The Apple WebDAV client also appears to have no problem. When it receives the truncated file from the first GET request, it follows up with a series of “Partial Content” GET requests, until it succeeds in retrieving the entire file. The Apache logs record the initial request as having succeeded with a 200 Status Code, and then the subsequent requests with a 206 (“Partial Content”) Status Code.
Other, less sophisticated clients, like the W3C Validator (for some reason, lots of visitors like to check the validity of the front page of this blog) meekly accept the partial content and try to do the best they can with it.
For what it’s worth, my version of Apache is freshly-compiled using gcc 4.0:
Apache/2.0.54 (Unix) DAV/2 mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/5.0.4
This is a very serious bug, affecting MacOSX 10.4 (Tiger) and Apache. I hope the good folks at Apple and the Apache Foundation find a solution soon.
In the meantime, if you do encounter truncated content from this server, try hitting Reload.
Update (5/25/2005):
Having a name for the problem is half the battle. Bug 34332. And, thanks to the great Wilfredo Sanchez, there’s even a fix. His patch works for the current APR trunk. But this one works against the APR version distributed with Apache 2.0.54.Hallelujah! My webserver is working again!
Re: Apache and Tiger
Hi,
It would be very nice if you could make it clear exactly WHAT the interaction between Tiger and Apache 2.0 that you are discussing is.
I have read the entire post carefully and I still cannot tell if what you are describing is
* Safari on Tiger has a problem with generic Apache 2 servers OR
* Apache 2 on Tiger has a problem.
Beyond that, if the problem is Apache 2 on Tiger, doesn’t at least Tiger Server come with Apache 2 as an option? So what’s the story there; does that one work?