aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt')
-rw-r--r--vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt560
1 files changed, 560 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt b/vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt
new file mode 100644
index 000000000..37d6808c3
--- /dev/null
+++ b/vendor/sabre/dav/docs/draft-nottingham-http-new-status-04.txt
@@ -0,0 +1,560 @@
+
+
+
+Network Working Group M. Nottingham
+Internet-Draft Rackspace
+Updates: 2616 (if approved) R. Fielding
+Intended status: Standards Track Adobe
+Expires: August 7, 2012 February 4, 2012
+
+
+ Additional HTTP Status Codes
+ draft-nottingham-http-new-status-04
+
+Abstract
+
+ This document specifies additional HyperText Transfer Protocol (HTTP)
+ status codes for a variety of common situations.
+
+Editorial Note (To be removed by RFC Editor before publication)
+
+ Distribution of this document is unlimited. Although this is not a
+ work item of the HTTPbis Working Group, comments should be sent to
+ the Hypertext Transfer Protocol (HTTP) mailing list at
+ ietf-http-wg@w3.org [1], which may be joined by sending a message
+ with subject "subscribe" to ietf-http-wg-request@w3.org [2].
+
+ Discussions of the HTTPbis Working Group are archived at
+ <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
+
+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 August 7, 2012.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 1]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. 428 Precondition Required . . . . . . . . . . . . . . . . . . . 3
+ 4. 429 Too Many Requests . . . . . . . . . . . . . . . . . . . . . 4
+ 5. 431 Request Header Fields Too Large . . . . . . . . . . . . . . 4
+ 6. 511 Network Authentication Required . . . . . . . . . . . . . . 5
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
+ Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
+ Appendix B. Issues Raised by Captive Portals . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 2]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+1. Introduction
+
+ This document specifies additional HTTP [RFC2616] status codes for a
+ variety of common situations, to improve interoperability and avoid
+ confusion when other, less precise status codes are used.
+
+ Note that these status codes are optional; servers cannot be required
+ to support them. However, because clients will treat unknown status
+ codes as a generic error of the same class (e.g., 499 is treated as
+ 400 if it is not recognized), they can be safely deployed by existing
+ servers (see [RFC2616] Section 6.1.1 for more information).
+
+
+2. Requirements
+
+ 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 [RFC2119].
+
+
+3. 428 Precondition Required
+
+ The 428 status code indicates that the origin server requires the
+ request to be conditional.
+
+ Its typical use is to avoid the "lost update" problem, where a client
+ GETs a resource's state, modifies it, and PUTs it back to the server,
+ when meanwhile a third party has modified the state on the server,
+ leading to a conflict. By requiring requests to be conditional, the
+ server can assure that clients are working with the correct copies.
+
+ Responses using this status code SHOULD explain how to resubmit the
+ request successfully. For example:
+
+ HTTP/1.1 428 Precondition Required
+ Content-Type: text/html
+
+ <html>
+ <head>
+ <title>Precondition Required</title>
+ </head>
+ <body>
+ <h1>Precondition Required</h1>
+ <p>This request is required to be conditional;
+ try using "If-Match".</p>
+ </body>
+ </html>
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 3]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ Responses with the 428 status code MUST NOT be stored by a cache.
+
+
+4. 429 Too Many Requests
+
+ The 429 status code indicates that the user has sent too many
+ requests in a given amount of time ("rate limiting").
+
+ The response representations SHOULD include details explaining the
+ condition, and MAY include a Retry-After header indicating how long
+ to wait before making a new request.
+
+ For example:
+
+ HTTP/1.1 429 Too Many Requests
+ Content-Type: text/html
+ Retry-After: 3600
+
+ <html>
+ <head>
+ <title>Too Many Requests</title>
+ </head>
+ <body>
+ <h1>Too Many Requests</h1>
+ <p>I only allow 50 requests per hour to this Web site per
+ logged in user. Try again soon.</p>
+ </body>
+ </html>
+
+ Note that this specification does not define how the origin server
+ identifies the user, nor how it counts requests. For example, an
+ origin server that is limiting request rates can do so based upon
+ counts of requests on a per-resource basis, across the entire server,
+ or even among a set of servers. Likewise, it might identify the user
+ by its authentication credentials, or a stateful cookie.
+
+ Responses with the 429 status code MUST NOT be stored by a cache.
+
+
+5. 431 Request Header Fields Too Large
+
+ The 431 status code indicates that the server is unwilling to process
+ the request because its header fields are too large. The request MAY
+ be resubmitted after reducing the size of the request header fields.
+
+ It can be used both when the set of request header fields in total
+ are too large, and when a single header field is at fault. In the
+ latter case, the response representation SHOULD specify which header
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 4]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ field was too large.
+
+ For example:
+
+ HTTP/1.1 431 Request Header Fields Too Large
+ Content-Type: text/html
+
+ <html>
+ <head>
+ <title>Request Header Fields Too Large</title>
+ </head>
+ <body>
+ <h1>Request Header Fields Too Large</h1>
+ <p>The "Example" header was too large.</p>
+ </body>
+ </html>
+
+ Responses with the 431 status code MUST NOT be stored by a cache.
+
+
+6. 511 Network Authentication Required
+
+ The 511 status code indicates that the client needs to authenticate
+ to gain network access.
+
+ The response representation SHOULD contain a link to a resource that
+ allows the user to submit credentials (e.g. with a HTML form).
+
+ Note that the 511 response SHOULD NOT contain a challenge or the
+ login interface itself, because browsers would show the login
+ interface as being associated with the originally requested URL,
+ which may cause confusion.
+
+ The 511 status SHOULD NOT be generated by origin servers; it is
+ intended for use by intercepting proxies that are interposed as a
+ means of controlling access to the network.
+
+ Responses with the 511 status code MUST NOT be stored by a cache.
+
+6.1. The 511 Status Code and Captive Portals
+
+ The 511 status code is designed to mitigate problems caused by
+ "captive portals" to software (especially non-browser agents) that is
+ expecting a response from the server that a request was made to, not
+ the intervening network infrastructure. It is not intended to
+ encouraged deployment of captive portals, only to limit the damage
+ caused by them.
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 5]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ A network operator wishing to require some authentication, acceptance
+ of terms or other user interaction before granting access usually
+ does so by identifing clients who have not done so ("unknown
+ clients") using their MAC addresses.
+
+ Unknown clients then have all traffic blocked, except for that on TCP
+ port 80, which is sent to a HTTP server (the "login server")
+ dedicated to "logging in" unknown clients, and of course traffic to
+ the login server itself.
+
+ For example, a user agent might connect to a network and make the
+ following HTTP request on TCP port 80:
+
+ GET /index.htm HTTP/1.1
+ Host: www.example.com
+
+ Upon receiving such a request, the login server would generate a 511
+ response:
+
+ HTTP/1.1 511 Network Authentication Required
+ Content-Type: text/html
+
+ <html>
+ <head>
+ <title>Network Authentication Required</title>
+ <meta http-equiv="refresh"
+ content="0; url=https://login.example.net/">
+ </head>
+ <body>
+ <p>You need to <a href="https://login.example.net/">
+ authenticate with the local network</a> in order to gain
+ access.</p>
+ </body>
+ </html>
+
+ Here, the 511 status code assures that non-browser clients will not
+ interpret the response as being from the origin server, and the META
+ HTML element redirects the user agent to the login server.
+
+
+7. Security Considerations
+
+7.1. 428 Precondition Required
+
+ The 428 status code is optional; clients cannot rely upon its use to
+ prevent "lost update" conflicts.
+
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 6]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+7.2. 429 Too Many Requests
+
+ When a server is under attack or just receiving a very large number
+ of requests from a single party, responding to each with a 429 status
+ code will consume resources.
+
+ Therefore, servers are not required to use the 429 status code; when
+ limiting resource usage, it may be more appropriate to just drop
+ connections, or take other steps.
+
+7.3. 431 Request Header Fields Too Large
+
+ Servers are not required to use the 431 status code; when under
+ attack, it may be more appropriate to just drop connections, or take
+ other steps.
+
+7.4. 511 Network Authentication Required
+
+ In common use, a response carrying the 511 status code will not come
+ from the origin server indicated in the request's URL. This presents
+ many security issues; e.g., an attacking intermediary may be
+ inserting cookies into the original domain's name space, may be
+ observing cookies or HTTP authentication credentials sent from the
+ user agent, and so on.
+
+ However, these risks are not unique to the 511 status code; in other
+ words, a captive portal that is not using this status code introduces
+ the same issues.
+
+ Also, note that captive portals using this status code on an SSL or
+ TLS connection (commonly, port 443) will generate a certificate error
+ on the client.
+
+
+8. IANA Considerations
+
+ The HTTP Status Codes Registry should be updated with the following
+ entries:
+
+ o Code: 428
+ o Description: Precondition Required
+ o Specification: [ this document ]
+
+ o Code: 429
+ o Description: Too Many Requests
+ o Specification: [ this document ]
+
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 7]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ o Code: 431
+ o Description: Request Header Fields Too Large
+ o Specification: [ this document ]
+
+ o Code: 511
+ o Description: Network Authentication Required
+ o Specification: [ this document ]
+
+
+9. References
+
+9.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.
+
+9.2. Informative References
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
+ "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+ March 2007.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+URIs
+
+ [1] <mailto:ietf-http-wg@w3.org>
+
+ [2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
+
+
+Appendix A. Acknowledgements
+
+ Thanks to Jan Algermissen and Julian Reschke for their suggestions
+ and feedback.
+
+
+Appendix B. Issues Raised by Captive Portals
+
+ Since clients cannot differentiate between a portal's response and
+ that of the HTTP server that they intended to communicate with, a
+ number of issues arise. The 511 status code is intended to help
+ mitigate some of them.
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 8]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ One example is the "favicon.ico"
+ <http://en.wikipedia.org/wiki/Favicon> commonly used by browsers to
+ identify the site being accessed. If the favicon for a given site is
+ fetched from a captive portal instead of the intended site (e.g.,
+ because the user is unauthenticated), it will often "stick" in the
+ browser's cache (most implementations cache favicons aggressively)
+ beyond the portal session, so that it seems as if the portal's
+ favicon has "taken over" the legitimate site.
+
+ Another browser-based issue comes about when P3P
+ <http://www.w3.org/TR/P3P/> is supported. Depending on how it is
+ implemented, it's possible a browser might interpret a portal's
+ response for the p3p.xml file as the server's, resulting in the
+ privacy policy (or lack thereof) advertised by the portal being
+ interpreted as applying to the intended site. Other Web-based
+ protocols such as WebFinger
+ <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>, CORS
+ <http://www.w3.org/TR/cors/> and OAuth
+ <http://tools.ietf.org/html/draft-ietf-oauth-v2> may also be
+ vulnerable to such issues.
+
+ Although HTTP is most widely used with Web browsers, a growing number
+ of non-browsing applications use it as a substrate protocol. For
+ example, WebDAV [RFC4918] and CalDAV [RFC4791] both use HTTP as the
+ basis (for remote authoring and calendaring, respectively). Using
+ these applications from behind a captive portal can result in
+ spurious errors being presented to the user, and might result in
+ content corruption, in extreme cases.
+
+ Similarly, other non-browser applications using HTTP can be affected
+ as well; e.g., widgets <http://www.w3.org/TR/widgets/>, software
+ updates, and other specialised software such as Twitter clients and
+ the iTunes Music Store.
+
+ It should be noted that it's sometimes believed that using HTTP
+ redirection to direct traffic to the portal addresses these issues.
+ However, since many of these uses "follow" redirects, this is not a
+ good solution.
+
+
+Authors' Addresses
+
+ Mark Nottingham
+ Rackspace
+
+ Email: mnot@mnot.net
+ URI: http://www.mnot.net/
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 9]
+
+Internet-Draft Additional HTTP Status Codes February 2012
+
+
+ Roy T. Fielding
+ Adobe Systems Incorporated
+ 345 Park Ave
+ San Jose, CA 95110
+ USA
+
+ Email: fielding@gbiv.com
+ URI: http://roy.gbiv.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Fielding Expires August 7, 2012 [Page 10]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-19 10:05:57 +0000