One document matched: draft-thomson-http-nice-00.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-00">
<front>
<title abbrev="HTTP Nice">
Marking HTTP Requests as Unimportant
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Microsoft</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>
<email>martin.thomson@skype.net</email>
</address>
</author>
<date year="2013"/>
<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 that marks a request as low
priority. Intermediaries can choose to discard the request or serve it 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 intermediary. 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>
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 intermediary 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 intermediary can generate an error response in response to a nice request, avoiding the
need to contact the constrained origin server. Alternatively, the intermediary 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 intermediaries 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>
</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,
an intermediary 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 intermediary 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 intermediary 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 intermediary about the threshold, or it might be provide specific information
that can be used, in conjunction with knowledge the intermediary 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
intermediary might use a heuristic with a moderate risk of false positives in
determining whether the server is available. An intermediary 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. An intermediary 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. An intermediary 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 intermediary.
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, an
intermediary 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>
<t>
Alternatively, requests can be held for an amount of time by the intermediary to be
forwarded when the origin server becomes available. 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 intermediary information about how long
the client is prepared to await a response. This could allow the intermediary to reject
the request immediately if the device is known to be unreachable for the entire duration.
</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"?>
</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"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:11 |