httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <>
Subject Re: [users@httpd] 500 status code responses, but the full/correct file contents are still sent to the user-agent
Date Fri, 02 Nov 2012 14:36:55 GMT

On 11/2/2012 5:35 AM, Tom Evans wrote:
> On Thu, Nov 1, 2012 at 6:09 PM, Ben Johnson <> wrote:
>> Might anyone know what could possibly cause Apache to return 500
>> (Internal Server Error) status code responses *but still return the
>> requested file's contents*?
>> I have reviewed the application logic carefully to ensure that no header
>> that includes the 500 status code is being sent from within the
>> application. (I searched the entire source-code tree for the string
>> "500" and confirmed that the string does not appear anywhere.)
>> I posted a couple of weeks ago about intermittent 500 errors in Apache's
>> access log, and noted that the response byte-lengths (the values
>> immediately after the status codes in the log entries) matched the
>> corresponding values when the status code was 200. In other words, it
>> seems that Apache always returns the full/correct content, even though
>> the status code is 500 intermittently.
>> Any help troubleshooting this problem would be greatly appreciated.
>> Thank you,
>> -Ben
> What is the application written in? "500" could be spelt
> "HTTP_INTERNAL_SERVER_ERROR", "HttpResponseServerError", etc.
> If Apache produces a 500 error response, it looks like an Apache 500
> error response, if it doesn't look like that, it is probably not
> Apache generating it.
> Cheers
> Tom

Tom, thanks for the reply.

The application is written in PHP. When you say, "if it looks like an
Apache 500 error response", are you referring to how the message looks
in the browser? Or in Apache's access log?

If you are referring to the browser, unfortunately, I'm unable to
reproduce the issue manually, so I don't know how it looks to the
user-agent. However, per my original post, it seems that the correct
document is actually returned, as evidenced by the response size, so I
don't think the user-agent ever sees an error message of any kind.
(Although, I do suspect that the user-agent receives the 500 response in
the header.)

IF you are referring to how the message looks in the log, here's a
sample entry:

[02/Nov/2012:06:01:57 -0700] "GET /download/ HTTP/1.1" 500
1023440 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)"

In this example, the request is to a file-delivery wrapper script, and
the requested file has a real size of 1,256,512 bytes on disk. This
script uses gzip compression (at the Apache layer), so it seems likely
that the response length in the log entry represents the gzipped file size.

If the user-agent is receiving the document/file, then why the 500 in
the log entry?

It may be worth mentioning that I have a copy of the same site on a
development server, which uses mod_php (whereas this problem server/site
uses FastCGI), and I don't see evidence of the problem there. So, maybe
it is related to CGI (I wrote a long post about my suspicions in that
regard earlier in this thread).

Thanks again,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message