One document matched: draft-thomson-http-nice-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-thomson-http-nice-01">
<front>
<title abbrev="HTTP Nice">
Marking HTTP Requests as Unimportant
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>331 E Evelyn Street</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date year="2014"/>
<area>Application</area>
<workgroup>HTTPBIS</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Unimportant</keyword>
<keyword>Nice</keyword>
<keyword>Priority</keyword>
<keyword>HTTP</keyword>
<keyword>CoAP</keyword>
<keyword>Battery</keyword>
<abstract>
<t>
An HTTP <spanx style="verb">Nice</spanx> header field is defined. <spanx
style="verb">Nice</spanx> marks a request as low priority. Gateways can choose to discard
or delay the request, or provide a response from cache rather than forwarding it to an
origin server. This enables constrained origin servers, such as those that rely on battery
power, to avoid expending limited resources on serving requests.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
<xref target="RFC2616">HTTP</xref> servers are beginning to appear as the interface to a
wide array of devices. Management interfaces in many devices have classically been provided
as HTTP servers, but this trend now extends to HTTP APIs on a range of devices, including
constrained devices. Constrained devices are those with limited processing power, network
connectivity or battery capacity.
</t>
<t>
The <xref target="I-D.ietf-core-coap">Constrained Application Protocol (CoAP)</xref> in
particular is designed to provide devices with extremely limited capabilities a way to
provide an HTTP-compatible interface to the information and services they provide. A <xref
target="I-D.ietf-core-http-mapping">CoAP-HTTP gateway</xref> provides HTTP-capable clients a
means of accessing these devices.
</t>
<t>
For a device that operates based on a battery, it is often crucial that the device remain
dormant for extended periods. Radio communication in particular consumes a significant
amount of power. Frequent communication limits the length of time that the device can
operate. It is often the case that communication can be initiated, but this could require a
significant expenditure of stored energy.
</t>
<t>
Many constrained devices rely on intermediaries such as the CoAP-HTTP gateway to terminate
requests and mediate access. Clients that access the services provided by such limited
devices can be unaware of the limited nature of the device serving the request, since they
actually interact with the gateway. Even when the client is aware of these limitatons,
it is not always possible for clients to learn whether any given request would cause
significant expenditure of resources at the constrained device.
</t>
<t>
A <xref target="I-D.thomson-webpush-http2">push server</xref> provides similar functionality
for devices with constrained resources. Providing a standard way to indicate that a request
is not urgent would allow a push server to discriminate between urgent and unimportant
requests.
</t>
<t>
This document defines an HTTP header field, <spanx style="verb">Nice</spanx> that can be
used by clients to indicate that a request is not urgent or important enough to cause a
constrained server to expend special effort to serve. An gateway that is aware that
the origin server is unable to handle the request can instead terminate the request. The
request is forwarded as normal to an origin server that is available.
</t>
<t>
An gateway can generate an error or 203 (Non-Authoritative Information) response in
response to a nice request, avoiding the need to contact the constrained origin server.
Alternatively, the gateway could delay the request until the origin server becomes
available or serve a response from cache if that is possible.
</t>
<t>
No specific mechanism is defined for an origin server to inform gateways of absence or
other indisposition.
</t>
<section anchor="terminology" title="Conventions and Terminology">
<t>
At times, this document falls back on shorthands for establishing interoperability
requirements on implementations: the capitalized words "MUST", "SHOULD" and "MAY". The
meaning of these is described in <xref target="RFC2119"/>.
</t>
<t>
The terms "intermediary" and "gateway" are defined in <xref
target="I-D.ietf-httpbis-p1-messaging"/>.
</t>
</section>
</section>
<section anchor="header" title="The Nice Header Field">
<t>
The <spanx style="verb">Nice</spanx> header field indicates that a request is less important
than a request that doesn't bear this header.
</t>
<t>
The value of the header field is a decimal number between 0 and 3 inclusive. Values greater
than zero indicate increasing levels of unimportance. A lower value indicates greater
urgency; for example, a value of 3 is less urgent or important than a value of 1. A value
of 0 (or an absent <spanx style="verb">Nice</spanx> header field) indicates that the request
is to be forwarded as normal.
</t>
<figure><artwork type="abnf"><![CDATA[
Nice = "Nice" ":" ("3" / "2" / "1" / "0")
]]></artwork></figure>
<t>
Multiple values for the header field MUST NOT be included. If multiple values are present,
a gateway MAY choose to treat the request in any way it chooses.
</t>
<figure>
<preamble>
For example, the following request indicates that it is not urgent:
</preamble>
<artwork><![CDATA[
GET /m HTTP/1.1
Host: device9710.example.net:11453
Nice: 2
]]></artwork>
</figure>
<figure>
<preamble>
An gateway might reject this request, indicating that the origin server is not
available using a 503 status code.
</preamble>
<artwork><![CDATA[
HTTP/1.1 503 Service Unavailable
Date: Fri, 26 Jul 2013
Content-Type: text/plain;charset=utf8
Content-Length: 63
The server is asleep, don't disturb it unless it's urgent.
]]></artwork>
</figure>
<t>
A key characteristic of this header field is that intermediaries and clients that do not
understand its semantics treat requests so marked no different to any other requests. An
intermediary that has no special information about the availability of the origin server
will also forward the request. That means that requests from a client that does not include
this header will always reach the origin server.
</t>
<section title="Policies for Treatment of Nice Requests">
<t>
An origin server or gateway might use several inputs in determing the threshold at
which a request is forwarded to the origin server. An origin server might either directly
instruct the gateway about the threshold, or it might be provide specific information
that can be used, in conjunction with knowledge the gateway has of the origin server,
as input to an algorithm for determining the threshold. Potential inputs include:
<list style="symbols">
<t>
The relative cost of awakening a dormant server. Depending on the server, this cost
may be assessed in different ways, including monetary, battery or time.
</t>
<t>
The last time that the server was in active communication. Typically, wireless
devices have a period of heightened availability just after sending or receiving data.
During this period activation and communication can be significantly more efficient.
</t>
<t>
Application preferences or context. For example, a server might be configured to be
more highly responsive to requests during certain times.
</t>
</list>
</t>
<t>
The following describes a potential set of policies regarding selection and treatment of
<spanx style="verb">Nice</spanx> header field value:
<list style="format nice: %d =">
<t>
The client regards the request as relatively urgent, but not critically so. An
gateway might use a heuristic with a moderate risk of false positives in determining
whether the server is available. A gateway might also forward a request so marked to
a dormant device that has a relatively low activation cost.
</t>
<t>
The client regards the request as not urgent. A gateway might attempt to minimize the
probability that it awakens a server, if it uses a heuristic in determining whether to
forward requests.
</t>
<t>
The client regards the request as being of trivial importance. A gateway might
avoid forwarding requests unless there is strong indication that the origin server is
available and willing to communicate.
</t>
</list>
</t>
<t>
Many different policies can be applied to the selection of a value for the <spanx
style="verb">Nice</spanx> header field, as well as to the treatment of requests so marked.
Specific applications might define a means for providing more specific policies.
</t>
</section>
<section title="Polling with Nice Requests">
<t>
Marking a request as nice is quite useful for requests that do not require immediate
action. Clients might wish to have the request fulfilled, but are willing to wait until
the origin server is present. Such requests might be sent periodically until they
succeed.
</t>
<t>
In some cases, origin server availability is predictable and known to the gateway. Some
devices have predictable cycles of availability, which are used for brief bursts of
communication. If the next time that the origin server is available is known, a gateway
can include a <spanx style="verb">Retry-After</spanx> header field in a generated error
response.
</t>
<figure>
<preamble>For example:</preamble>
<artwork><![CDATA[
HTTP/1.1 503 Service Unavailable
Date: Fri, 26 Jul 2013 03:34:19 GMT
Retry-After: 4
]]></artwork>
</figure>
</section>
<section title="Store and Forward">
<t>
A gateway MAY hold requests for a limited amount of time, to be forwarded when the origin
server becomes available (i.e., a "store and forward" mode of operation). Including a
<spanx style="verb">Prefer</spanx> header field <xref target="I-D.snell-http-prefer"/>
with the <spanx style="verb">wait</spanx> tag provides the gateway information about
how long the client is prepared to await a response. This could allow the gateway to
reject the request immediately if the device is known to be unreachable for the entire
duration.
</t>
<t>
Gateways MAY alternatively accept a request and return an immediate response, such as a
202 (Accepted) status code. Use of the <spanx style="verb">respond-async</spanx> token in
the <spanx style="verb">Prefer</spanx> header field allows clients to expressly request
this behavior.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Lowering the priority with which a request is handled is unlikely to cause any special
concern with respect to security.
</t>
<t>
Intermediaries that do not support the <spanx style="verb">Nice</spanx> header field might
erroneously cache a response from an intermediary that handles the request without
forwarding to the origin server. Intermediaries MUST NOT generate cacheable responses to
requests containing an <spanx style="verb">Nice</spanx> header field. Intermediaries MAY
however provide cached responses originally provided by the origin server.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
The permanent message header field registry (see <xref target="RFC3864"/>) has been updated
with the following registration:
<list style="hanging">
<t hangText="Header field name:">
Nice
</t>
<t hangText="Applicable protocol:">
http
</t>
<t hangText="Status:">
standard
</t>
<t hangText="Author/Change controller:">
IETF
</t>
<t hangText="Specification document:">
this specification (<xref target="header"/>)
</t>
</list>
</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>
The original idea for this header field was devised by Matthew Kaufman and Bruce Lowekamp,
who realized the importance of making the header a negative rather than positive expression
of priority.
</t>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-p1-messaging.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.snell-http-prefer.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-http-mapping.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-webpush-http2.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:04:57 |