Don't use HTTP 403 Forbidden for protected entries.
Short, concise description of the idea
I think you should never receive HTTP 403 (Forbidden) when trying to visit a Read Comments page.
Full description of the idea
This suggestion is somewhat technical in nature, but I'm posting it here because it would have non-technical ramifications. You can have an opinion on this without knowing or caring about the HTTP spec.
Currently, when you attempt to view an S2 Read Comments page, and aren't logged in as someone who can view the relevant entry, you receive an HTTP 403 error (Forbidden) [example]. I suggest instead an HTTP 200 response (OK) that explains the problem, as is currently the case with site-schemed Read Comments pages [example].
If this description is unclear at all, let me know and I'll try to improve it.
An ordered list of benefits
- I think this would bring better standards-compliance, since I think this is a misuse of HTTP 403.
- I think this would produce a more helpful error message. It could tell the viewer that they need to log in, that the entry is protected, etc., rather than simply that the URL represents a "forbidden" resource, as though people knew what that meant. (With the current behavior, it looks as though LJ had messed up.)
- Using a normal HTTP 200 error page would enable more coherent navigation - an HTML page could be served with links back to content. (Note: Even with HTTP 403, a useful HTML page could be served; but users with IE would never get to see that page, since IE provides its own error page when it receives an HTTP 403 response.) Update: timwi has said in the comments here that at as long as the HTML error page is big enough, IE will display it. In light of this, I don't think it's a huge deal if we use HTTP 403. The important thing is to get a full error page.
An ordered list of problems/issues involved
- Well, not everyone might like their S2 style being ignored on such pages (though that's the case anyway now; it would just be more blatant if a site-scheme page were served rather than an HTTP 403).
- If you have any other thoughts, please share them! :-)
An organized list, or a few short paragraphs detailing suggestions for implementation
- I'm not sure how it would work from the back-end.
- From the front-end, the S2 style can simply be ignored when the entry can't be shown anyway. That is, at S2 Read Comments pages that currently return HTTP 403, present an old-fashioned HTTP 200 Read Comments page.
- In the longer term, this could be incorporated into this suggestion.