https://bz.apache.org/bugzilla/show_bug.cgi?id=53602
--- Comment #7 from Rainer Jung <rainer.j...@kippdata.de> --- 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. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org