W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Status code for censorship?

From: Dereq Dereq <dereq@japan.com>
Date: Tue, 10 Jul 2012 04:33:16 -0400
Cc: ietf-http-wg@w3.org
Message-ID: <20120710083316.298430@gmx.com>
To: "Martin Thomson" <martin.thomson@gmail.com>,"Tim Bray" <tbray@textuality.com>
>The temptation to suggest 418 is strong, but 403 is essentially >correct. The entity making the authorization decision might not be >the usual or expected one, but that is the decision they are making. There are two general reasons to limit 403 to responses from the origin server. 1. As you say, the situation that you are discussing is not usual or expected. Hence it is more transparent and more helpful to highlight it explicitly. Some variation on the principle of least astonishment applies here. (For example, what if the end user getting the status code is the owner / operator of the origin server?) It is understood that in some jurisdictions use of a response code other than 403, or other than some other specified response code, may not be legal. It is also understood that some censoring entities will choose not to do the right thing. However the HTTP RFC should still specify what the correct behaviour is. If the law prevents some software from behaving correctly or some other software chooses to behaveincorrectly then so be it. There should still be a defined correct behaviour available for software that is willing and able to do so. That behaviour should be to be transparent about what has occurred. 451 is cute but I don't really care whether it's 451 or some other free 4xx code. 2. The actions that a user (or software) would take when 403 arises from the origin server and when censorship arises between an HTTP client and the origin server are quite different. When 403 arises from the origin server it is an indication that there is a fundamental difficulty with the request. The server that "owns" the resource is saying that it can't be accessed. The user may have to try e.g. different login credentials or e.g. contact the operator of the web server (if it's just a stuff up - or to be granted access). When censorship arises, the user will probably want to tunnel the request in some way but it is unlikely that either of the courses of action given as examples in the previous paragraph are going to make an difference.
Received on Tuesday, 10 July 2012 08:33:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC