If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.
Joyous differences between “SHOULD NOT” and “MUST NOT” aside, I’m finding that every browser’s implementation of 204 No Content creates a usability problem. Lets break the process down.
What the spec appears to state
- User agent (web browser) loads a document (web page).
- User interacts with the document via the user agent to load a new document (clicking a link on the web page).
- Server responds with 204 No Content
- User agent active view (the window/tab the first document was loaded in) does not change, allowing
for actions to take place without causing a change to the user agent’s active document view
(js alert boxes set on a timeout so many seconds after an anchor tag has been clicked ?).
How browser implementation of 204 No Content causes a usability problem.
- User agent (web browser) loads a document (web page). Example (Codie’s land listing on sw.slr)
- User interacts with the user agent- not the document in active view- to load a new document (clicking a bookmark or manually pasting in an URL). Example (Marv’s land listing on sw.slr)
- User agent active view does not change.
A Usability Problem
In the example, it appears to the average user that the second document is identical to the first, or if Codie were to sell all her land and sims, and the page was loaded by clicking a bookmark for the same active view as a previous version of the document, it would appear that Codie still owns regions.
The issue of 204 No Content as a usability problem doesn’t appear to lie with the HTTP spec. It explicitly states it SHOULD NOT change its document view from that which caused the request to be sent
. However, it seems to be the case that a User Agent’s UI is not part of the document view, so the HTTP spec should not need to be updated in order to clarify this (given the diversity of applications, the protocol spec really shouldn’t make any attempt to reference any UI elements past, present or future possibilities).
It seems that browsers (perhaps all browsers) are at fault here, though on first glance it doesn’t seem to be that big a deal- you could say “Why not use 404 Not Found instead ?”. Yes, 404 Not Found could indeed get around the usability problem, as it allows a message body to be sent alongside the response- whereas 204 No Content MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
. However, 204 No Content is for when the server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.
, and 404 is for when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable
. Semantically speaking (in my examples), with 204 No Content, the server is saying “Yes, I understood your request, but there’s nothing to see, though I might have some extra info relating to your request.”, but with 404 Not Found, the server is saying “Okay, nothing to see here”.
In short…
In short, if the HTTP spec does not mean to include a user agent’s UI in it’s “active view”, then the behaviour of all browsers needs to change so that the user is informed- either via an alert or error page- if a 204 No Content header is received in response to an attempt to load a document from anywhere other than the document in the “active view” (bookmarks, manual paste/type, browser extensions, external programs).
