Index: java/org/apache/tomcat/util/http/res/LocalStrings.properties =================================================================== --- java/org/apache/tomcat/util/http/res/LocalStrings.properties (revision 1365543) +++ java/org/apache/tomcat/util/http/res/LocalStrings.properties (working copy) @@ -65,6 +65,7 @@ sc.428=Precondition Required sc.429=Too Many Requests sc.431=Request Header Fields Too Large +sc.451=Unavailable For Legal Reasons sc.500=Internal Server Error sc.501=Not Implemented sc.502=Bad Gateway Submitting as enhancement instead of committing in case anyone has an objection.
Link to versions of the proposal to add this new status code to HTTP in IETF document tracking tool: https://datatracker.ietf.org/doc/draft-tbray-http-legally-restricted-status/history/ The current version of the document is "01". I do not mind adding the new status code, but the comment in the LocalStrings.properties file says that the codes come from IANA page, http://www.iana.org/assignments/http-status-codes/http-status-codes.xml Either a comment should be added on where the code comes from, or we can wait until a proper RFC is issued and IANA page is updated with the new code.
OK to add for me. The IANA link I added to the comments wasn't meant to police other status code additions but instead to be useful for future checks. So Tim, you might want to adjust that comment as you see fit. There are two places with HTTP status codes: tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties tomcat/trunk/java/org/apache/tomcat/util/http/res/LocalStrings.properties You might want to add the new one to the other list as well. Regards, Rainer
Wait. Why add a status code that hasn't been approved yet? The spec might go nowhere. Or it might be approved, but with a different status code.
This (and any other new codes) can be added once they are approved.
(In reply to Mark Thomas from comment #4) > This (and any other new codes) can be added once they are approved. +1 Any webapp that wants to use code 451 (amusing code, eh?) with a response message can manually set the message until such time as Tomcat supports it (due to standards approval).
Changing from RESOLVED LATER to REOPENED and moving from Tomcat 7 to Tomcat 9. (In reply to Konstantin Kolinko from comment #1) > I do not mind adding the new status code, but the comment in the > LocalStrings.properties file says that the codes come from IANA page, > http://www.iana.org/assignments/http-status-codes/http-status-codes.xml > > Either a comment should be added on where the code comes from, or we can > wait until a proper RFC is issued and IANA page is updated with the new code. The IANA page has been updated and now lists the code 451 as assigned and links to the following draft. The draft linked from IANA page has a different name, https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/ Its History page says that it has been approved on 2015-12-21. Apparently it has not been published as an RFC yet, but it is going to become one. A blog post and Wikipedia: https://www.mnot.net/blog/2015/12/18/451 https://en.wikipedia.org/wiki/HTTP_451
Additional info. The RFC draft https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/?include_text=1 says: Responses using this status code SHOULD include an explanation, in the response body, of the details of the legal demand: the party making it, the applicable legislation or regulation, and what classes of person and resource it applies to. For example: HTTP/1.1 451 Unavailable For Legal Reasons Link: <https://spqr.example.org/legislatione>; rel="blocked-by" Content-Type: text/html <html> <head><title>Unavailable For Legal Reasons</title></head> <body> <h1>Unavailable For Legal Reasons</h1> <p>This request may not be serviced in the Roman Province of Judea due to the Lex Julia Majestatis, which disallows access to resources hosted on servers deemed to be operated by the People's Front of Judea.</p> </body> </html> And furthermore: As noted above, when an attempt to access a resource fails with status 451, the entity blocking access might or might not be the origin server. There are a variety of entities in the resource- access path which could choose to deny access, for example ISPs, cache providers, and DNS servers. It is useful, when legal blockages occur, to be able to identify the entities actually implementing the blocking. When an entity blocks access to a resource and returns status 451, it SHOULD include a "Link" HTTP header field [RFC5988] whose value is a URI reference [RFC3986] identifying itself. When used for this purpose, the "Link" header field MUST have a "rel" parameter whose value is "blocked-by". The intent is that the header be used to identify the entity actually implementing blockage, not any other entity mandating it. A human readable response body, as discussed above, is the appropriate location for discussion of administrative and policy issues. Just in case anyone is interested in more support than simply adding status code and reason phrase.
Fixed in: - trunk for 9.0.0.M16 onwards - 8.5.x for 8.5.10 onwards - 8.0.x for 8.0.40 onwards - 7.0.x for 7.0.74 onwards