<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
<!ENTITY rfc2119 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4084 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4084.xml'>
<!ENTITY rfc4924 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4924.xml'>
<!ENTITY rfc7234 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml'>
<!ENTITY rfc3986 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc5988 SYSTEM 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5988.xml'>
<!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
<!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
<!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
<!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
<!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
<!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
<!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
<!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
<!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
<!ENTITY mdash "&#8212;">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext html-pretty-print="prettyprint https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"?>

<rfc number="7725" 
     category="std"
     xmlns:x="http://purl.org/net/xml2rfc/ext">

  <front>
    <title abbrev="HTTP-status-451">An HTTP Status Code to Report Legal Obstacles</title>
    <author initials="T." surname="Bray" fullname="Tim Bray">
      <organization>Textuality</organization>
      <address>
      	<email>tbray@textuality.com</email>
      	<uri>http://www.tbray.org/ongoing/</uri>
      </address>
    </author>

    <date year="2016" month="February"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>HTTP</keyword>

    <abstract>

      <t>This document specifies a Hypertext Transfer Protocol (HTTP) 
      status code for use when resource access is denied as a
      consequence of legal demands.</t>

    </abstract>

  </front>

  <middle>

    <section title="Introduction">
      <t>This document specifies a Hypertext Transfer Protocol (HTTP) 
      status code for use when a server operator has received a legal
      demand to deny access to a resource or to a set of resources that
      includes the requested resource.</t>

      <t>This status code can be used to provide transparency
      in circumstances where issues of law or public policy affect server
      operations. This transparency may be beneficial both to these operators
      and to end users.</t>
      <t><xref target="RFC4924"/> discusses the forces working
      against transparent operation of the Internet; these clearly include
      legal interventions to restrict access to content.  As that document
      notes, and as <xref target="RFC4084" x:fmt="of" x:sec="4"/> states, such
      restrictions should be made explicit.</t>
    </section>

    <section title="Requirements">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
      this document are to be interpreted as described in <xref
      target="RFC2119"/>.</t>
    </section>


    <section title="451 Unavailable For Legal Reasons">
      <t>This status code indicates that the server is denying access
      to the resource as a consequence of a legal demand.</t> 
      
      <t>The server in question might not be an origin server.  This type of
      legal demand typically most directly affects the operations of ISPs and
      search engines.</t>

      <t>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:</t>

      <figure><artwork type="message/http; msgtype=&#34;response&#34;">
HTTP/1.1 451 Unavailable For Legal Reasons
Link: &lt;https://spqr.example.org/legislatione>; rel="blocked-by"
Content-Type: text/html

<x:span x:lang="">&lt;html>
 &lt;head>&lt;title>Unavailable For Legal Reasons&lt;/title>&lt;/head>
 &lt;body>
  &lt;h1>Unavailable For Legal Reasons&lt;/h1>
  &lt;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.&lt;/p>
 &lt;/body>
&lt;/html></x:span></artwork></figure>

<t>The use of the 451 status code implies neither the existence nor
nonexistence of the resource named in the request. That is to say,
it is possible that if the legal demands were removed,
a request for the resource still might not succeed.</t>

<t>Note that in many cases clients can still access the denied resource by
using technical countermeasures such as a VPN or the Tor network.</t>

<t>A 451 response is cacheable by default, i.e., unless otherwise indicated by the method definition or explicit cache controls; see <xref target="RFC7234"/>.</t>
    </section>

    <section title="Identifying Blocking Entities">
      <t>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 that could choose to deny access &mdash; for example, ISPs,
      cache providers, and DNS servers.</t>
      <t>It is useful, when legal blockages occur, to be able to identify the
      entities actually implementing the blocking.</t>
      <t>When an entity blocks access to a resource and returns status 451, it
      &SHOULD; include a "Link" HTTP header field <xref target="RFC5988"/>
      whose value is a URI reference <xref target="RFC3986"/>
      identifying itself.  When used for this purpose, the "Link" header field
      &MUST; have a "rel" parameter whose value is "blocked-by".</t>
      <t>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.</t>
    </section>

    <section title="Security Considerations">

      <t>Clients cannot rely upon the use of the 451 status code.
      It is possible that certain legal authorities might wish
      to avoid transparency, and not only demand the restriction of access 
      to certain resources, but also avoid disclosing that the demand 
      was made.  </t>

    </section>

    <section title="IANA Considerations">
      <t>The HTTP Status Codes Registry has been updated with the
      following entry:</t>

      <t><list style="symbols">
	<t>Code: 451</t>
	<t>Description: Unavailable For Legal Reasons</t>
	<t>Specification: RFC 7725</t>
      </list></t>

      <t>The Link Relation Type Registry has been updated with the
      following entry:</t>
      <t><list style="symbols">
	<t>Relation Name: blocked-by</t>
	<t>Description: Identifies the entity that blocks access to a resource
	following receipt of a legal demand.</t>
	<t>Reference: RFC 7725</t>
      </list></t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc7234;
      &rfc3986;
      &rfc5988;
    </references>

    <references title="Informative References">
      &rfc4084;
      &rfc4924;
    </references>

    <section title="Acknowledgements">
      <t>Thanks to Terence Eden, who observed that the existing
      status code 403 was not really suitable for this situation, and
      suggested the creation of a new status code.</t>
      <t>Thanks also to Ray Bradbury.</t>
    </section>


  </back>
</rfc>
