[In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]
Synopsis: GET /track1.mp3 from localhost returns no HTTP headers. State-Changed-From-To: analyzed-feedback State-Changed-By: fielding State-Changed-When: Sun Sep 13 16:09:27 PDT 1998 State-Changed-Why: I was not able to reproduce this problem using 1.3.2-dev and a small test file. I would have tested it with the original mp3 file, but the reported server is not up. Have you tested the problem with 1.3.1 or later? In any case, aside from the simple possibilities that Marc already mentioned, a difference between the localhost and normal server address would likely be due to a difference in server configuration on a per-address basis or a buffer overflow in a reverse DNS lookup, neither of which can be tested easily. Does the server have multiple configurations for different IP addresses (address-based virtual hosts)? It looks like HostnameLookups is set to off, since otherwise the logfile would say "localhost" instead of 127.0.0.1. If it is in fact set to "on" or "double" and the lookup is failing, then that is the likely source of the problem. Severity has been reset to non-critical because nobody ever accesses a web server using "localhost" under normal circumstances. Severity-Changed-From-To: serious-non-critical Severity-Changed-By: fielding Severity-Changed-When: Sun Sep 13 16:09:27 PDT 1998
