Bug 53602

Summary: Support for HTTP status code 451
Product: Tomcat 9 Reporter: Tim Funk <funkman>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: P2    
Version: unspecified   
Target Milestone: -----   
Hardware: All   
OS: All   

Description Tim Funk 2012-07-25 12:08:14 UTC
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.
Comment 1 Konstantin Kolinko 2012-07-25 12:37:41 UTC
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.
Comment 2 Rainer Jung 2012-07-25 13:42:28 UTC
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
Comment 3 Julian Reschke 2012-07-26 06:41:00 UTC
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.
Comment 4 Mark Thomas 2013-09-12 14:42:26 UTC
This (and any other new codes) can be added once they are approved.
Comment 5 Christopher Schultz 2013-09-13 14:19:11 UTC
(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).
Comment 6 Konstantin Kolinko 2015-12-24 05:36:05 UTC
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
Comment 7 Rainer Jung 2016-02-09 15:09:04 UTC
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.
Comment 8 Mark Thomas 2017-01-03 20:19:30 UTC
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