[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
HTTPBIS                                                       M. Thomson
Internet-Draft                                                 Microsoft
Intended status: Standards Track                         August 15, 2013
Expires: February 16, 2014


                  Marking HTTP Requests as Unimportant
                       draft-thomson-http-nice-00

Abstract

   An HTTP "Nice" 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.












Thomson                 Expires February 16, 2014               [Page 1]


Internet-Draft                  HTTP Nice                    August 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  The Nice Header Field . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Policies for Treatment of Nice Requests . . . . . . . . .   4
     2.2.  Polling with Nice Requests  . . . . . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   HTTP [RFC2616] 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.

   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] 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 CoAP-HTTP gateway
   [I-D.ietf-core-http-mapping] provides HTTP-capable clients a means of
   accessing these devices.

   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.




Thomson                 Expires February 16, 2014               [Page 2]


Internet-Draft                  HTTP Nice                    August 2013


   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.

   This document defines an HTTP header field, "Nice" 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.

   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.

   No specific mechanism is defined for an origin server to inform
   intermediaries of absence or other indisposition.

1.1.  Conventions and Terminology

   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 [RFC2119].

2.  The Nice Header Field

   The "Nice" header field indicates that a request is less important
   than a request that doesn't bear this header.

   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 "Nice" header field) indicates that the request is
   to be forwarded as normal.

   Nice  = "Nice" ":" ("3" / "2" / "1" / "0")






Thomson                 Expires February 16, 2014               [Page 3]


Internet-Draft                  HTTP Nice                    August 2013


   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.

   For example, the following request indicates that it is not urgent:

   GET /m HTTP/1.1
   Host: device9710.example.net:11453
   Nice: 2


   An intermediary might reject this request, indicating that the origin
   server is not available using a 503 status code.

   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.


   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.

2.1.  Policies for Treatment of Nice Requests

   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:

   o  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.








Thomson                 Expires February 16, 2014               [Page 4]


Internet-Draft                  HTTP Nice                    August 2013


   o  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.

   o  Application preferences or context.  For example, a server might
      be configured to be more highly responsive to requests during
      certain times.

   The following describes a potential set of policies regarding
   selection and treatment of "Nice" header field value:

   nice: 1 =  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.

   nice: 2 =  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.

   nice: 3 =  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.

   Many different policies can be applied to the selection of a value
   for the "Nice" header field, as well as to the treatment of requests
   so marked.  Specific applications might define a means for providing
   more specific policies.

2.2.  Polling with Nice Requests

   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.









Thomson                 Expires February 16, 2014               [Page 5]


Internet-Draft                  HTTP Nice                    August 2013


   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 "Retry-After" header field in a generated
   error response.

   For example:

   HTTP/1.1 503 Service Unavailable
   Date: Fri, 26 Jul 2013 03:34:19 GMT
   Retry-After: 4


   Alternatively, requests can be held for an amount of time by the
   intermediary to be forwarded when the origin server becomes
   available.  Including a "Prefer" header field [I-D.snell-http-prefer]
   with the "wait" 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.

3.  Security Considerations

   Lowering the priority with which a request is handled is unlikely to
   cause any special concern with respect to security.

   Intermediaries that do not support the "Nice" 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 "Nice"
   header field.  Intermediaries MAY however provide cached responses
   originally provided by the origin server.

4.  IANA Considerations

   The permanent message header field registry (see [RFC3864]) has been
   updated with the following registration:

   Header field name:  Nice

   Applicable protocol:  http

   Status:  standard

   Author/Change controller:  IETF

   Specification document:  this specification (Section 2)



Thomson                 Expires February 16, 2014               [Page 6]


Internet-Draft                  HTTP Nice                    August 2013


5.  Acknowledgements

   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.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

6.2.  Informative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

   [I-D.ietf-core-http-mapping]
              Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Best Practices for HTTP-CoAP Mapping
              Implementation", draft-ietf-core-http-mapping-01 (work in
              progress), July 2013.

   [I-D.snell-http-prefer]
              Snell, J., "Prefer Header for HTTP", draft-snell-http-
              prefer-18 (work in progress), January 2013.

Author's Address

   Martin Thomson
   Microsoft
   3210 Porter Drive
   Palo Alto, CA  94304
   US

   Email: martin.thomson@skype.net




Thomson                 Expires February 16, 2014               [Page 7]