HTTP Status Codes on IIS6

Sigh. People are too quick to apply Harlon's Razor and assume that any "deviations" result from malicious Microsoft intent to deviate from HTTP standard, when user misinformation is frequently the problem...

Question:

I have a problem with a customer which is using IIS based on windows 2003. The question is simple all these deviations from the normal HTTP standard presented on IIS see following link: https://support.microsoft.com/default.aspx?scid=kb;EN-US;318380

Are they actually sent downstream to the end-user?

Here is the corresponding RFC. https://www.w3.org/Protocols/HTTP/1.0/draft-ietf-http-spec.html

Ideas or places to find this information?

Thanks for your help.
Best regards,

Answer:

IIS6 on Windows Server 2003 is an HTTP/1.1 Server. Your referenced RFC applies to an HTTP/1.0 Server... so it does not apply here at all. The actual HTTP/1.1 RFC which does apply to IIS6 is at:

https://www.w3.org/Protocols/rfc2616/rfc2616.html

If you quickly browse through the official HTTP/1.1 RFC, you should see that IIS is not deviating from the normal HTTP standard at all, so there are no problems with sending custom error responses using those status codes.

And even in the case of 401, 403, 404, 500, and 502, where IIS offers sub-status error codes to differentiate amongst the standard HTTP status codes, IIS is still compliant with HTTP specifications. IIS simply sends HTTP responses using the standard HTTP status code and gives you rich control of the exact content to send for the sub-stataus error. And if you use URL Custom Error to execute arbitrary code to generate the custom error response, you also control the returned HTTP status code well.

For example, when IIS detects that the client IP is banned by your server's IP Restriction configuration, it triggers a 403.6 error internally, and you can configure the 403.6 custom error to generate a 403 response with your custom content to inform the user of this restriction. Simultaneously, when IIS detects that the browser is making an HTTP request to a virtual directory requiring HTTPS, it triggers a 403.4 error internally, and you can configure the 403.4 custom error to generate a 403 response with different custom content to automatically meta-redirect the browser from HTTP to HTTPS.

In both cases, the browser sees standard 403 responses according to HTTP specification, but you, as the server administrator, have rich control of the user experience depending on the sub-status error code and react accordingly - to either sternly ignore the banned users while gently redirecting good users who forgot to type HTTPS.

IMHO, in the case of HTTP status codes, IIS does the Right Thing and provides users and administrators with the right feature set. It follows HTTP/1.1 specification while allowing the server administrator flexibility to customize server behavior to result in good user experiences. This results in a win-win for standards, administrators, and users.

//David

Comments

• Anonymous
  March 31, 2006
  The comment has been removed