robert hahn

a darn good web developer

April 11, 2007

A Question About Using 403 Forbidden

From here:

403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

Consider the following scenario: You have a web-based application that uses HTTP Authentication, and there are URIs that authorized people may edit. Here are the sample URIs:

/shipment/9879
/shipment/form/9879

You may recognize the design of these URIs from my previous post on URI Design. The difference between the URIs is that the second one pulls up a form prepopulated with shipment 9879, whereas the first is merely a read-only representation. Assume that only HTTP Authenticated users may edit the shipment.

Consider the scenario where an authenticated user wishes to share the data on this page with a group of people, some of whom have authorization to edit the resource. An unauthorized person clicks on /shipment/form/9879 and should (correctly?) get a 403 code.

Now, the developer would very much like to make life easy for people using the site. There are a number of possible ways to resolve this:

Unauthorized users will get a 403 code, and whatever /shipment/9879 would have returned, plus an error message explaining the problem.
Unauthorized users will get a 302, redirecting to /shipment/9879; no mention of the error is logged.
Unauthorized users will get a 200, but the returned representation is identical to /shipment/9879
Unauthorized users will get a 403 code, a helpful error message, and a link to /shipment/9879
???

My gut feeling is to go with 1 or 2, saving the users a click. What do you think?