Patrick Cooney's Weblog

When a HTTP 500 means something else entirely

2004-02-11

When an ASP page experiences an error, a HTTP 5xx message is often returned to the client, indicating some server error. Anyone who has coded some ASP (badly) will know the drill on this. While working on some web page caching problems, I got to thinking about the effect of Response.Buffer = true and Response.Flush calls that precede a server error - in this circumstance, the client is going to get a response header (a 200, say), and then... kaboom. They will probably get a load of strack trace or whatever else the web server is configured to give them in the event of an error. But no 500.

The funny thing about this is that on my IIS6, the logs say 500 in this situation, not 200. So in some circumstances I could send my client a 200 + a load of junk, but log it as a 500 on the server side. This presents some challenges for my spelunking of cache problems - did the client really get a 500, or some other code? This is important to me, because HTTP 1.1 makes some interesting statements regarding caching and 5xxs:

"If a cache receives a 5xx response while attempting to revalidate an entry, it may either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return previously received response unless the cached entry includes the “must-revalidate” Cache- Control directive." (Section 13.8, RFC 2068)

This doesn't get me any closer to solving my caching problem, but it has been fun getting into the nitty gritty of HTTP.

Back to weblog