How misleading and then helpful are built-in server error pages in SharePoint?

There are number of best practices while building an error page. One of these practices is the status code of the response. The are a lot of different types of errors, but the most common are 404 for Not Found and 500 for Internal Server Error.

One of the critical things about SharePoint built-in server error pages that response status code is 200 OK and not 500 Internal Server Error. The same is happening for 401 Unauthorized errors. SharePoint built-in error pages hide both errors and return 200 OK status code.

SP-Error-AccessDenied

In a SharePoint site, you can reach Site Features or Site Collections Features via ManageFeatures.aspx page. If I'm passing an improper query string value to the page, an error occurred but the response code is 200 OK.

SP-Error-500-ManageFeatures

This is not good! Suppose there is an automated job that performs number of background tasks e.g. page loading test, automated checks of users permissions etc... in that case, the request has succeeded despite the fact that an error has occurred.

The 200 response has extra headers that are more interesting; SPRequestGuid and SharePointError.

SP-Error-ResponseHeaders

SPRequestGuid is a unique identifier for each request to the site that can be used to provide diagnostic information to users. This is included in response headers even if there weren't any errors.

SharePointError indicates if a server error has occurred or not? Zero means a server error has occurred.

The value of SPRequestGuid is the same as error Correlation ID and that makes it easier to report that an error has occurred and share error Correlation ID / Request Identifier.

SP-Error-CorrelationID

Although that sounds helpful to identify if an error has occurred but setting the response status code to 500 or the actual error code will make it more helpful and more aligned with error pages best practices.

Show Comments