1 | <?xml version="1.0" encoding="utf-8"?> |
---|
2 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
3 | <!DOCTYPE rfc [ |
---|
4 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
5 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
6 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
7 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
8 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
9 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
10 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
11 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
12 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
13 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
14 | <!ENTITY ID-VERSION "latest"> |
---|
15 | <!ENTITY ID-MONTH "March"> |
---|
16 | <!ENTITY ID-YEAR "2012"> |
---|
17 | <!ENTITY mdash "—"> |
---|
18 | <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
19 | <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
20 | <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
21 | <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
22 | <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
23 | <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
24 | <!ENTITY range "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
25 | <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
26 | <!ENTITY auth "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
27 | <!ENTITY content-negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
28 | <!ENTITY agent-driven-negotiation "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
29 | <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
30 | <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
31 | <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
32 | <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
33 | <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
34 | <!ENTITY intermediaries "<xref target='Part1' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
35 | <!ENTITY chunked-encoding "<xref target='Part1' x:rel='#chunked.encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
36 | <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
37 | <!ENTITY http-version "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
38 | <!ENTITY use100 "<xref target='Part1' x:rel='#use.of.the.100.status' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
39 | <!ENTITY qvalue "<xref target='Part3' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
40 | <!ENTITY request-target "<xref target='Part1' x:rel='#request-target' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
41 | <!ENTITY header-accept "<xref target='Part3' x:rel='#header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
42 | <!ENTITY header-accept-charset "<xref target='Part3' x:rel='#header.accept-charset' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
43 | <!ENTITY header-accept-encoding "<xref target='Part3' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
44 | <!ENTITY header-accept-language "<xref target='Part3' x:rel='#header.accept-language' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
45 | <!ENTITY header-accept-ranges "<xref target='Part5' x:rel='#header.accept-ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
46 | <!ENTITY header-age "<xref target='Part6' x:rel='#header.age' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
47 | <!ENTITY header-authorization "<xref target='Part7' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
48 | <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
49 | <!ENTITY header-connection "<xref target='Part1' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
50 | <!ENTITY header-content-location "<xref target='Part3' x:rel='#header.content-location' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
51 | <!ENTITY header-content-range "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
52 | <!ENTITY header-content-type "<xref target='Part3' x:rel='#header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
53 | <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
54 | <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
55 | <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
56 | <!ENTITY header-host "<xref target='Part1' x:rel='#header.host' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
57 | <!ENTITY header-if-match "<xref target='Part4' x:rel='#header.if-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
58 | <!ENTITY header-if-modified-since "<xref target='Part4' x:rel='#header.if-modified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
59 | <!ENTITY header-if-none-match "<xref target='Part4' x:rel='#header.if-none-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
60 | <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
61 | <!ENTITY header-if-unmodified-since "<xref target='Part4' x:rel='#header.if-unmodified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
62 | <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
63 | <!ENTITY header-proxy-authenticate "<xref target='Part7' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
64 | <!ENTITY header-proxy-authorization "<xref target='Part7' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
65 | <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
66 | <!ENTITY header-upgrade "<xref target='Part1' x:rel='#header.upgrade' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
67 | <!ENTITY header-te "<xref target='Part1' x:rel='#header.te' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
68 | <!ENTITY header-vary "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
69 | <!ENTITY header-via "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
70 | <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
71 | <!ENTITY header-www-authenticate "<xref target='Part7' x:rel='#header.www-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
72 | <!ENTITY media-types "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
73 | <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
74 | <!ENTITY media-type-message-http "<xref target='Part1' x:rel='#internet.media.type.message.http' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
75 | <!ENTITY status-206 "<xref target='Part5' x:rel='#status.206' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
76 | <!ENTITY status-304 "<xref target='Part4' x:rel='#status.304' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
77 | <!ENTITY status-401 "<xref target='Part7' x:rel='#status.401' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
78 | <!ENTITY status-407 "<xref target='Part7' x:rel='#status.407' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
79 | <!ENTITY status-412 "<xref target='Part4' x:rel='#status.412' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
80 | <!ENTITY status-416 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
81 | <!ENTITY p3-header-fields "<xref target='Part3' x:rel='#header.field.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
82 | <!ENTITY p4-status-codes "<xref target='Part4' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
83 | <!ENTITY p5-status-codes "<xref target='Part5' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
84 | <!ENTITY p7-status-codes "<xref target='Part7' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
85 | <!ENTITY p6-heuristic "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
86 | <!ENTITY p6-explicit "<xref target='Part6' x:rel='#calculating.freshness.lifetime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
87 | <!ENTITY p6-invalid "<xref target='Part6' x:rel='#invalidation.after.updates.or.deletions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
88 | <!ENTITY p6-head "<xref target='Part6' x:rel='#head.effects' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
89 | <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
90 | <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
91 | <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
92 | <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
93 | <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
94 | <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
95 | <!ENTITY caching-neg-resp "<xref target='Part6' x:rel='#caching.negotiated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
96 | <!ENTITY header-transfer-encoding "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
97 | <!ENTITY header-content-length "<xref target='Part1' x:rel='#header.content-length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
98 | <!ENTITY header-content-range "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
99 | <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
100 | <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
101 | <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
102 | <!ENTITY header-user-agent "<xref target='Part2' x:rel='#header.user-agent' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
103 | <!ENTITY header-vary "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
104 | <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
105 | <!ENTITY multipart-byteranges "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
106 | <!ENTITY http-date "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
107 | <!ENTITY qvalue "<xref target='Part1' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
108 | <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
109 | <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
110 | <!ENTITY compression-codings "<xref target='Part1' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
111 | <!ENTITY transfer-codings "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
112 | <!ENTITY compress-coding "<xref target='Part1' x:rel='#compress.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
113 | <!ENTITY deflate-coding "<xref target='Part1' x:rel='#deflate.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
114 | <!ENTITY gzip-coding "<xref target='Part1' x:rel='#gzip.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
115 | <!ENTITY response-representation "<xref target='Part2' x:rel='#identifying.response.associated.with.representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
116 | ]> |
---|
117 | <?rfc toc="yes" ?> |
---|
118 | <?rfc symrefs="yes" ?> |
---|
119 | <?rfc sortrefs="yes" ?> |
---|
120 | <?rfc compact="yes"?> |
---|
121 | <?rfc subcompact="no" ?> |
---|
122 | <?rfc linkmailto="no" ?> |
---|
123 | <?rfc editing="no" ?> |
---|
124 | <?rfc comments="yes"?> |
---|
125 | <?rfc inline="yes"?> |
---|
126 | <?rfc rfcedstyle="yes"?> |
---|
127 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
128 | <?rfc-ext include-references-in-index="yes" ?> |
---|
129 | <rfc obsoletes="2616" updates="2817" category="std" x:maturity-level="proposed" |
---|
130 | ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" |
---|
131 | xmlns:x='http://purl.org/net/xml2rfc/ext' |
---|
132 | xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'> |
---|
133 | <x:link rel="prev" basename="p1-messaging"/> |
---|
134 | <x:link rel="next" basename="p3-payload"/> |
---|
135 | <x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&body=<{ref}>:"/> |
---|
136 | <front> |
---|
137 | |
---|
138 | <title abbrev="HTTP/1.1, Part 2">HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation</title> |
---|
139 | |
---|
140 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
141 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
142 | <address> |
---|
143 | <postal> |
---|
144 | <street>345 Park Ave</street> |
---|
145 | <city>San Jose</city> |
---|
146 | <region>CA</region> |
---|
147 | <code>95110</code> |
---|
148 | <country>USA</country> |
---|
149 | </postal> |
---|
150 | <email>fielding@gbiv.com</email> |
---|
151 | <uri>http://roy.gbiv.com/</uri> |
---|
152 | </address> |
---|
153 | </author> |
---|
154 | |
---|
155 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
156 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
157 | <address> |
---|
158 | <postal> |
---|
159 | <street>W3C / ERCIM</street> |
---|
160 | <street>2004, rte des Lucioles</street> |
---|
161 | <city>Sophia-Antipolis</city> |
---|
162 | <region>AM</region> |
---|
163 | <code>06902</code> |
---|
164 | <country>France</country> |
---|
165 | </postal> |
---|
166 | <email>ylafon@w3.org</email> |
---|
167 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
168 | </address> |
---|
169 | </author> |
---|
170 | |
---|
171 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
172 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
173 | <address> |
---|
174 | <postal> |
---|
175 | <street>Hafenweg 16</street> |
---|
176 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
177 | <country>Germany</country> |
---|
178 | </postal> |
---|
179 | <phone>+49 251 2807760</phone> |
---|
180 | <facsimile>+49 251 2807761</facsimile> |
---|
181 | <email>julian.reschke@greenbytes.de</email> |
---|
182 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
183 | </address> |
---|
184 | </author> |
---|
185 | |
---|
186 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
187 | <workgroup>HTTPbis Working Group</workgroup> |
---|
188 | |
---|
189 | <abstract> |
---|
190 | <t> |
---|
191 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for |
---|
192 | distributed, collaborative, hypertext information systems. HTTP has been in |
---|
193 | use by the World Wide Web global information initiative since 1990. This |
---|
194 | document is Part 2 of the seven-part specification that defines the protocol |
---|
195 | referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
---|
196 | </t> |
---|
197 | <t> |
---|
198 | Part 2 defines the semantics of HTTP messages as expressed by request |
---|
199 | methods, request header fields, response status codes, and response header |
---|
200 | fields. Furthermore, it defines HTTP message content, metadata, and content |
---|
201 | negotiation. |
---|
202 | <cref>#351</cref> |
---|
203 | </t> |
---|
204 | </abstract> |
---|
205 | |
---|
206 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
207 | <t> |
---|
208 | Discussion of this draft should take place on the HTTPBIS working group |
---|
209 | mailing list (ietf-http-wg@w3.org), which is archived at |
---|
210 | <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>. |
---|
211 | </t> |
---|
212 | <t> |
---|
213 | The current issues list is at |
---|
214 | <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related |
---|
215 | documents (including fancy diffs) can be found at |
---|
216 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
217 | </t> |
---|
218 | <t> |
---|
219 | The changes in this draft are summarized in <xref target="changes.since.19"/>. |
---|
220 | </t> |
---|
221 | </note> |
---|
222 | </front> |
---|
223 | <middle> |
---|
224 | <section title="Introduction" anchor="introduction"> |
---|
225 | <t> |
---|
226 | This document defines HTTP/1.1 request and response semantics. Each HTTP |
---|
227 | message, as defined in &messaging;, is in the form of either a request or |
---|
228 | a response. An HTTP server listens on a connection for HTTP requests and |
---|
229 | responds to each request, in the order received on that connection, with |
---|
230 | one or more HTTP response messages. This document defines the commonly |
---|
231 | agreed upon semantics of the HTTP uniform interface, the intentions defined |
---|
232 | by each request method, and the various response messages that might be |
---|
233 | expected as a result of applying that method to the target resource. |
---|
234 | </t> |
---|
235 | <t> |
---|
236 | Furthermore, it defines HTTP/1.1 message payloads (a.k.a., content), the |
---|
237 | associated metadata header fields that define how the payload is intended |
---|
238 | to be interpreted by a recipient, the request header fields that |
---|
239 | might influence content selection, and the various selection algorithms |
---|
240 | that are collectively referred to as HTTP content negotiation. |
---|
241 | <cref>#351</cref> |
---|
242 | </t> |
---|
243 | <t> |
---|
244 | This document is currently disorganized in order to minimize the changes |
---|
245 | between drafts and enable reviewers to see the smaller errata changes. |
---|
246 | A future draft will reorganize the sections to better reflect the content. |
---|
247 | In particular, the sections will be ordered according to the typical |
---|
248 | processing of an HTTP request message (after message parsing): resource |
---|
249 | mapping, methods, request modifying header fields, response status, |
---|
250 | status modifying header fields, and resource metadata. The current mess |
---|
251 | reflects how widely dispersed these topics and associated requirements |
---|
252 | had become in <xref target="RFC2616"/>. |
---|
253 | </t> |
---|
254 | |
---|
255 | <section title="Terminology" anchor="terminology"> |
---|
256 | <t> |
---|
257 | This specification uses a number of terms to refer to the roles |
---|
258 | played by participants in, and objects of, the HTTP communication. |
---|
259 | </t> |
---|
260 | <t> |
---|
261 | <iref item="content negotiation"/> |
---|
262 | <x:dfn>content negotiation</x:dfn> |
---|
263 | <list> |
---|
264 | <t> |
---|
265 | The mechanism for selecting the appropriate representation when |
---|
266 | servicing a request. The representation in any response |
---|
267 | can be negotiated (including error responses). |
---|
268 | </t> |
---|
269 | </list> |
---|
270 | </t> |
---|
271 | <t> |
---|
272 | <iref primary="true" item="selected representation"/> |
---|
273 | <x:dfn>selected representation</x:dfn> |
---|
274 | <list> |
---|
275 | <t> |
---|
276 | The current representation of the target resource that would have been |
---|
277 | selected in a successful response if the same request had used the |
---|
278 | method GET and excluded any conditional request header fields. |
---|
279 | </t> |
---|
280 | </list> |
---|
281 | </t> |
---|
282 | </section> |
---|
283 | |
---|
284 | <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> |
---|
285 | <t> |
---|
286 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
287 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
288 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
289 | </t> |
---|
290 | <t> |
---|
291 | This document defines conformance criteria for several roles in HTTP |
---|
292 | communication, including Senders, Recipients, Clients, Servers, User-Agents, |
---|
293 | Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; |
---|
294 | for definitions of these terms. |
---|
295 | </t> |
---|
296 | <t> |
---|
297 | An implementation is considered conformant if it complies with all of the |
---|
298 | requirements associated with its role(s). Note that SHOULD-level requirements |
---|
299 | are relevant here, unless one of the documented exceptions is applicable. |
---|
300 | </t> |
---|
301 | <t> |
---|
302 | This document also uses ABNF to define valid protocol elements |
---|
303 | (<xref target="notation"/>). In addition to the prose requirements placed |
---|
304 | upon them, Senders &MUST-NOT; generate protocol elements that are invalid. |
---|
305 | </t> |
---|
306 | <t> |
---|
307 | Unless noted otherwise, Recipients &MAY; take steps to recover a usable |
---|
308 | protocol element from an invalid construct. However, HTTP does not define |
---|
309 | specific error handling mechanisms, except in cases where it has direct |
---|
310 | impact on security. This is because different uses of the protocol require |
---|
311 | different error handling strategies; for example, a Web browser may wish to |
---|
312 | transparently recover from a response where the Location header field |
---|
313 | doesn't parse according to the ABNF, whereby in a systems control protocol |
---|
314 | using HTTP, this type of error recovery could lead to dangerous consequences. |
---|
315 | </t> |
---|
316 | </section> |
---|
317 | |
---|
318 | <section title="Syntax Notation" anchor="notation"> |
---|
319 | <x:anchor-alias value="ALPHA"/> |
---|
320 | <x:anchor-alias value="CR"/> |
---|
321 | <x:anchor-alias value="DIGIT"/> |
---|
322 | <x:anchor-alias value="LF"/> |
---|
323 | <x:anchor-alias value="OCTET"/> |
---|
324 | <x:anchor-alias value="SP"/> |
---|
325 | <x:anchor-alias value="VCHAR"/> |
---|
326 | <t> |
---|
327 | This specification uses the Augmented Backus-Naur Form (ABNF) notation |
---|
328 | of <xref target="RFC5234"/> with the list rule extension defined in |
---|
329 | ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF |
---|
330 | with the list rule expanded. |
---|
331 | </t> |
---|
332 | <t> |
---|
333 | The following core rules are included by |
---|
334 | reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: |
---|
335 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
336 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
337 | HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), |
---|
338 | OCTET (any 8-bit sequence of data), SP (space), and |
---|
339 | VCHAR (any visible US-ASCII character). |
---|
340 | </t> |
---|
341 | |
---|
342 | <section title="Core Rules" anchor="core.rules"> |
---|
343 | <x:anchor-alias value="obs-text"/> |
---|
344 | <x:anchor-alias value="quoted-string"/> |
---|
345 | <x:anchor-alias value="token"/> |
---|
346 | <x:anchor-alias value="word"/> |
---|
347 | <x:anchor-alias value="BWS"/> |
---|
348 | <x:anchor-alias value="OWS"/> |
---|
349 | <x:anchor-alias value="RWS"/> |
---|
350 | <t> |
---|
351 | The core rules below are defined in <xref target="Part1"/>: |
---|
352 | </t> |
---|
353 | <figure><artwork type="abnf2616"> |
---|
354 | <x:ref>BWS</x:ref> = <BWS, defined in &whitespace;> |
---|
355 | <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> |
---|
356 | <x:ref>RWS</x:ref> = <RWS, defined in &whitespace;> |
---|
357 | <x:ref>obs-text</x:ref> = <obs-text, defined in &field-components;> |
---|
358 | <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> |
---|
359 | <x:ref>token</x:ref> = <token, defined in &field-components;> |
---|
360 | <x:ref>word</x:ref> = <word, defined in &field-components;> |
---|
361 | </artwork></figure> |
---|
362 | </section> |
---|
363 | |
---|
364 | <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> |
---|
365 | <x:anchor-alias value="absolute-URI"/> |
---|
366 | <x:anchor-alias value="comment"/> |
---|
367 | <x:anchor-alias value="partial-URI"/> |
---|
368 | <x:anchor-alias value="qvalue"/> |
---|
369 | <x:anchor-alias value="URI-reference"/> |
---|
370 | <t> |
---|
371 | The ABNF rules below are defined in other parts: |
---|
372 | </t> |
---|
373 | <figure><!--Part1--><artwork type="abnf2616"> |
---|
374 | <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> |
---|
375 | <x:ref>comment</x:ref> = <comment, defined in &field-components;> |
---|
376 | <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> |
---|
377 | <x:ref>URI-reference</x:ref> = <URI-reference, defined in &uri;> |
---|
378 | </artwork></figure> |
---|
379 | </section> |
---|
380 | </section> |
---|
381 | </section> |
---|
382 | |
---|
383 | <section title="Methods" anchor="methods"> |
---|
384 | <x:anchor-alias value="method"/> |
---|
385 | <t> |
---|
386 | The method token indicates the request method to be performed on the target |
---|
387 | resource (&effective-request-uri;). The method is case-sensitive. |
---|
388 | </t> |
---|
389 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="method"/> |
---|
390 | <x:ref>method</x:ref> = <x:ref>token</x:ref> |
---|
391 | </artwork></figure> |
---|
392 | <t> |
---|
393 | The list of methods allowed by a resource can be specified in an |
---|
394 | Allow header field (<xref target="header.allow"/>). The status code of the response |
---|
395 | always notifies the client whether a method is currently allowed on a |
---|
396 | resource, since the set of allowed methods can change dynamically. An |
---|
397 | origin server &SHOULD; respond with the status code 405 (Method Not Allowed) |
---|
398 | if the method is known by the origin server but not allowed for the |
---|
399 | resource, and 501 (Not Implemented) if the method is |
---|
400 | unrecognized or not implemented by the origin server. The methods GET |
---|
401 | and HEAD &MUST; be supported by all general-purpose servers. All other |
---|
402 | methods are &OPTIONAL;; however, if the above methods are implemented, |
---|
403 | they &MUST; be implemented with the same semantics as those specified |
---|
404 | in <xref target="method.definitions"/>. |
---|
405 | </t> |
---|
406 | |
---|
407 | <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent"> |
---|
408 | |
---|
409 | <section title="Safe Methods" anchor="safe.methods"> |
---|
410 | <iref item="Safe Methods" primary="true"/> |
---|
411 | <t> |
---|
412 | Implementors need to be aware that the software represents the user in |
---|
413 | their interactions over the Internet, and need to allow |
---|
414 | the user to be aware of any actions they take which might have an |
---|
415 | unexpected significance to themselves or others. |
---|
416 | </t> |
---|
417 | <t> |
---|
418 | In particular, the convention has been established that the GET, HEAD, |
---|
419 | OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance |
---|
420 | of taking an action other than retrieval. These request methods ought |
---|
421 | to be considered "<x:dfn anchor="safe">safe</x:dfn>". |
---|
422 | This allows user agents to represent other methods, such as POST, PUT |
---|
423 | and DELETE, in a special way, so that the user is made aware of the |
---|
424 | fact that a possibly unsafe action is being requested. |
---|
425 | </t> |
---|
426 | <t> |
---|
427 | Naturally, it is not possible to ensure that the server does not |
---|
428 | generate side-effects as a result of performing a GET request; in |
---|
429 | fact, some dynamic resources consider that a feature. The important |
---|
430 | distinction here is that the user did not request the side-effects, |
---|
431 | so therefore cannot be held accountable for them. |
---|
432 | </t> |
---|
433 | </section> |
---|
434 | |
---|
435 | <section title="Idempotent Methods" anchor="idempotent.methods"> |
---|
436 | <iref item="Idempotent Methods" primary="true"/> |
---|
437 | <t> |
---|
438 | Request methods can also have the property of "idempotence" in that, |
---|
439 | aside from error or expiration issues, the intended effect of multiple |
---|
440 | identical requests is the same as for a single request. |
---|
441 | PUT, DELETE, and all safe request methods are idempotent. |
---|
442 | It is important to note that idempotence refers only to changes |
---|
443 | requested by the client: a server is free to change its state due |
---|
444 | to multiple requests for the purpose of tracking those requests, |
---|
445 | versioning of results, etc. |
---|
446 | </t> |
---|
447 | </section> |
---|
448 | </section> |
---|
449 | |
---|
450 | <section title="Method Registry" anchor="method.registry"> |
---|
451 | <t> |
---|
452 | The HTTP Method Registry defines the name space for the method token in the |
---|
453 | Request line of an HTTP request. |
---|
454 | </t> |
---|
455 | <t> |
---|
456 | Registrations &MUST; include the following fields: |
---|
457 | <list style="symbols"> |
---|
458 | <t>Method Name (see <xref target="methods"/>)</t> |
---|
459 | <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t> |
---|
460 | <t>Pointer to specification text</t> |
---|
461 | </list> |
---|
462 | </t> |
---|
463 | <t> |
---|
464 | Values to be added to this name space require IETF Review |
---|
465 | (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). |
---|
466 | </t> |
---|
467 | <t> |
---|
468 | The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>. |
---|
469 | </t> |
---|
470 | |
---|
471 | <section title="Considerations for New Methods" anchor="considerations.for.new.methods"> |
---|
472 | <t> |
---|
473 | When it is necessary to express new semantics for a HTTP request that |
---|
474 | aren't specific to a single application or media type, and currently defined |
---|
475 | methods are inadequate, it may be appropriate to register a new method. |
---|
476 | </t> |
---|
477 | <t> |
---|
478 | HTTP methods are generic; that is, they are potentially applicable to any |
---|
479 | resource, not just one particular media type, "type" of resource, or |
---|
480 | application. As such, it is preferred that new HTTP methods be registered |
---|
481 | in a document that isn't specific to a single application, so that this is |
---|
482 | clear. |
---|
483 | </t> |
---|
484 | <t> |
---|
485 | Due to the parsing rules defined in &message-body;, definitions of HTTP |
---|
486 | methods cannot prohibit the presence of a message body on either the request |
---|
487 | or the response message (with responses to HEAD requests being the single |
---|
488 | exception). Definitions of new methods cannot change this rule, but they can |
---|
489 | specify that only zero-length bodies (as opposed to absent bodies) are allowed. |
---|
490 | </t> |
---|
491 | <t> |
---|
492 | New method definitions need to indicate whether they are safe (<xref |
---|
493 | target="safe.methods"/>), what semantics (if any) the request body has, |
---|
494 | and whether they are idempotent (<xref target="idempotent.methods"/>). |
---|
495 | They also need to state whether they can be cached (&caching;); in |
---|
496 | particular what conditions a cache may store the response, and under what |
---|
497 | conditions such a stored response may be used to satisfy a subsequent |
---|
498 | request. |
---|
499 | </t> |
---|
500 | </section> |
---|
501 | </section> |
---|
502 | |
---|
503 | <section title="Method Definitions" anchor="method.definitions"> |
---|
504 | |
---|
505 | <section title="OPTIONS" anchor="OPTIONS"> |
---|
506 | <rdf:Description> |
---|
507 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
508 | </rdf:Description> |
---|
509 | <iref primary="true" item="OPTIONS method" x:for-anchor=""/> |
---|
510 | <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/> |
---|
511 | <t> |
---|
512 | The OPTIONS method requests information about the |
---|
513 | communication options available on the request/response chain |
---|
514 | identified by the effective request URI. This method allows a client to |
---|
515 | determine the options and/or requirements associated with a resource, |
---|
516 | or the capabilities of a server, without implying a resource action |
---|
517 | or initiating a resource retrieval. |
---|
518 | </t> |
---|
519 | <t> |
---|
520 | Responses to the OPTIONS method are not cacheable. |
---|
521 | </t> |
---|
522 | <t> |
---|
523 | If the OPTIONS request includes a message body (as indicated by the |
---|
524 | presence of Content-Length or Transfer-Encoding), then the media type |
---|
525 | &MUST; be indicated by a Content-Type field. Although this |
---|
526 | specification does not define any use for such a body, future |
---|
527 | extensions to HTTP might use the OPTIONS body to make more detailed |
---|
528 | queries on the server. |
---|
529 | </t> |
---|
530 | <t> |
---|
531 | If the request-target (&request-target;) is an asterisk ("*"), |
---|
532 | the OPTIONS request is |
---|
533 | intended to apply to the server in general rather than to a specific |
---|
534 | resource. Since a server's communication options typically depend on |
---|
535 | the resource, the "*" request is only useful as a "ping" or "no-op" |
---|
536 | type of method; it does nothing beyond allowing the client to test |
---|
537 | the capabilities of the server. For example, this can be used to test |
---|
538 | a proxy for HTTP/1.1 conformance (or lack thereof). |
---|
539 | </t> |
---|
540 | <t> |
---|
541 | If the request-target is not an asterisk, the OPTIONS request applies |
---|
542 | only to the options that are available when communicating with that |
---|
543 | resource. |
---|
544 | </t> |
---|
545 | <t> |
---|
546 | A 200 response &SHOULD; include any header fields that indicate |
---|
547 | optional features implemented by the server and applicable to that |
---|
548 | resource (e.g., Allow), possibly including extensions not defined by |
---|
549 | this specification. The response body, if any, &SHOULD; also include |
---|
550 | information about the communication options. The format for such a |
---|
551 | body is not defined by this specification, but might be defined by |
---|
552 | future extensions to HTTP. Content negotiation &MAY; be used to select |
---|
553 | the appropriate response format. If no response body is included, the |
---|
554 | response &MUST; include a Content-Length field with a field-value of |
---|
555 | "0". |
---|
556 | </t> |
---|
557 | <t> |
---|
558 | The Max-Forwards header field &MAY; be used to target a |
---|
559 | specific proxy in the request chain (see <xref target="header.max-forwards"/>). |
---|
560 | If no Max-Forwards field is present in the request, then the forwarded |
---|
561 | request &MUST-NOT; include a Max-Forwards field. |
---|
562 | </t> |
---|
563 | </section> |
---|
564 | |
---|
565 | <section title="GET" anchor="GET"> |
---|
566 | <rdf:Description> |
---|
567 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
568 | </rdf:Description> |
---|
569 | <iref primary="true" item="GET method" x:for-anchor=""/> |
---|
570 | <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/> |
---|
571 | <t> |
---|
572 | The GET method requests transfer of a current representation of |
---|
573 | the target resource. |
---|
574 | </t> |
---|
575 | <t> |
---|
576 | If the target resource is a data-producing process, it is the |
---|
577 | produced data which shall be returned as the representation in the response and not |
---|
578 | the source text of the process, unless that text happens to be the output of |
---|
579 | the process. |
---|
580 | </t> |
---|
581 | <t> |
---|
582 | The semantics of the GET method change to a "conditional GET" if the |
---|
583 | request message includes an If-Modified-Since, If-Unmodified-Since, |
---|
584 | If-Match, If-None-Match, or If-Range header field. A conditional GET |
---|
585 | requests that the representation be transferred only under the |
---|
586 | circumstances described by the conditional header field(s). The |
---|
587 | conditional GET request is intended to reduce unnecessary network |
---|
588 | usage by allowing cached representations to be refreshed without requiring |
---|
589 | multiple requests or transferring data already held by the client. |
---|
590 | </t> |
---|
591 | <t> |
---|
592 | The semantics of the GET method change to a "partial GET" if the |
---|
593 | request message includes a Range header field. A partial GET requests |
---|
594 | that only part of the representation be transferred, as described in &header-range;. |
---|
595 | The partial GET request is intended to reduce unnecessary |
---|
596 | network usage by allowing partially-retrieved representations to be |
---|
597 | completed without transferring data already held by the client. |
---|
598 | </t> |
---|
599 | <t> |
---|
600 | Bodies on GET requests have no defined semantics. Note that sending a body |
---|
601 | on a GET request might cause some existing implementations to reject the |
---|
602 | request. |
---|
603 | </t> |
---|
604 | <t> |
---|
605 | The response to a GET request is cacheable and &MAY; be used to satisfy |
---|
606 | subsequent GET and HEAD requests (see &caching;). |
---|
607 | </t> |
---|
608 | <t> |
---|
609 | See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms. |
---|
610 | </t> |
---|
611 | </section> |
---|
612 | |
---|
613 | <section title="HEAD" anchor="HEAD"> |
---|
614 | <rdf:Description> |
---|
615 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
616 | </rdf:Description> |
---|
617 | <iref primary="true" item="HEAD method" x:for-anchor=""/> |
---|
618 | <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/> |
---|
619 | <t> |
---|
620 | The HEAD method is identical to GET except that the server &MUST-NOT; |
---|
621 | return a message body in the response. The metadata contained |
---|
622 | in the HTTP header fields in response to a HEAD request &SHOULD; be identical |
---|
623 | to the information sent in response to a GET request. This method can |
---|
624 | be used for obtaining metadata about the representation implied by the |
---|
625 | request without transferring the representation body. This method is |
---|
626 | often used for testing hypertext links for validity, accessibility, |
---|
627 | and recent modification. |
---|
628 | </t> |
---|
629 | <t> |
---|
630 | The response to a HEAD request is cacheable and &MAY; be used to satisfy |
---|
631 | a subsequent HEAD request. It also has potential side effects on |
---|
632 | previously stored responses to GET; see &p6-head;. |
---|
633 | </t> |
---|
634 | <t> |
---|
635 | Bodies on HEAD requests have no defined semantics. Note that sending a body |
---|
636 | on a HEAD request might cause some existing implementations to reject the |
---|
637 | request. |
---|
638 | </t> |
---|
639 | </section> |
---|
640 | |
---|
641 | <section title="POST" anchor="POST"> |
---|
642 | <iref primary="true" item="POST method" x:for-anchor=""/> |
---|
643 | <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/> |
---|
644 | <t> |
---|
645 | The POST method requests that the origin server accept the |
---|
646 | representation enclosed in the request as data to be processed by the |
---|
647 | target resource. POST is designed to allow a uniform method to cover the |
---|
648 | following functions: |
---|
649 | <list style="symbols"> |
---|
650 | <t> |
---|
651 | Annotation of existing resources; |
---|
652 | </t> |
---|
653 | <t> |
---|
654 | Posting a message to a bulletin board, newsgroup, mailing list, |
---|
655 | or similar group of articles; |
---|
656 | </t> |
---|
657 | <t> |
---|
658 | Providing a block of data, such as the result of submitting a |
---|
659 | form, to a data-handling process; |
---|
660 | </t> |
---|
661 | <t> |
---|
662 | Extending a database through an append operation. |
---|
663 | </t> |
---|
664 | </list> |
---|
665 | </t> |
---|
666 | <t> |
---|
667 | The actual function performed by the POST method is determined by the |
---|
668 | server and is usually dependent on the effective request URI. |
---|
669 | </t> |
---|
670 | <t> |
---|
671 | The action performed by the POST method might not result in a |
---|
672 | resource that can be identified by a URI. In this case, either 200 |
---|
673 | (OK) or 204 (No Content) is the appropriate response status code, |
---|
674 | depending on whether or not the response includes a representation that |
---|
675 | describes the result. |
---|
676 | </t> |
---|
677 | <t> |
---|
678 | If a resource has been created on the origin server, the response |
---|
679 | &SHOULD; be 201 (Created) and contain a representation which describes the |
---|
680 | status of the request and refers to the new resource, and a Location |
---|
681 | header field (see <xref target="header.location"/>). |
---|
682 | </t> |
---|
683 | <t> |
---|
684 | Responses to POST requests are only cacheable when they |
---|
685 | include explicit freshness information (see &p6-explicit;). A |
---|
686 | cached POST response with a Content-Location header field |
---|
687 | (see &header-content-location;) whose value is the effective |
---|
688 | Request URI &MAY; be used to satisfy subsequent GET and HEAD requests. |
---|
689 | </t> |
---|
690 | <t> |
---|
691 | Note that POST caching is not widely implemented. |
---|
692 | However, the 303 (See Other) response can be used to direct the |
---|
693 | user agent to retrieve a cacheable representation of the resource. |
---|
694 | </t> |
---|
695 | </section> |
---|
696 | |
---|
697 | <section title="PUT" anchor="PUT"> |
---|
698 | <iref primary="true" item="PUT method" x:for-anchor=""/> |
---|
699 | <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> |
---|
700 | <t> |
---|
701 | The PUT method requests that the state of the target resource |
---|
702 | be created or replaced with the state defined by the representation |
---|
703 | enclosed in the request message payload. A successful PUT of a given |
---|
704 | representation would suggest that a subsequent GET on that same target |
---|
705 | resource will result in an equivalent representation being returned in |
---|
706 | a 200 (OK) response. However, there is no guarantee that such a state |
---|
707 | change will be observable, since the target resource might be acted |
---|
708 | upon by other user agents in parallel, or might be subject to dynamic |
---|
709 | processing by the origin server, before any subsequent GET is received. |
---|
710 | A successful response only implies that the user agent's intent was |
---|
711 | achieved at the time of its processing by the origin server. |
---|
712 | </t> |
---|
713 | <t> |
---|
714 | If the target resource does not have a current representation and |
---|
715 | the PUT successfully creates one, then the origin server &MUST; inform |
---|
716 | the user agent by sending a 201 (Created) response. If the target |
---|
717 | resource does have a current representation and that representation is |
---|
718 | successfully modified in accordance with the state of the enclosed |
---|
719 | representation, then either a 200 (OK) or 204 (No Content) response |
---|
720 | &SHOULD; be sent to indicate successful completion of the request. |
---|
721 | </t> |
---|
722 | <t> |
---|
723 | Unrecognized header fields &SHOULD; be ignored (i.e., not saved |
---|
724 | as part of the resource state). |
---|
725 | </t> |
---|
726 | <t> |
---|
727 | An origin server &SHOULD; verify that the PUT representation is |
---|
728 | consistent with any constraints which the server has for the target |
---|
729 | resource that cannot or will not be changed by the PUT. This is |
---|
730 | particularly important when the origin server uses internal |
---|
731 | configuration information related to the URI in order to set the |
---|
732 | values for representation metadata on GET responses. When a PUT |
---|
733 | representation is inconsistent with the target resource, the origin |
---|
734 | server &SHOULD; either make them consistent, by transforming the |
---|
735 | representation or changing the resource configuration, or respond |
---|
736 | with an appropriate error message containing sufficient information |
---|
737 | to explain why the representation is unsuitable. The 409 (Conflict) |
---|
738 | or 415 (Unsupported Media Type) status codes are suggested, with the |
---|
739 | latter being specific to constraints on Content-Type values. |
---|
740 | </t> |
---|
741 | <t> |
---|
742 | For example, if the target resource is configured to always have a |
---|
743 | Content-Type of "text/html" and the representation being PUT has a |
---|
744 | Content-Type of "image/jpeg", then the origin server &SHOULD; do one of: |
---|
745 | (a) reconfigure the target resource to reflect the new media type; |
---|
746 | (b) transform the PUT representation to a format consistent with that |
---|
747 | of the resource before saving it as the new resource state; or, |
---|
748 | (c) reject the request with a 415 response indicating that the target |
---|
749 | resource is limited to "text/html", perhaps including a link to a |
---|
750 | different resource that would be a suitable target for the new |
---|
751 | representation. |
---|
752 | </t> |
---|
753 | <t> |
---|
754 | HTTP does not define exactly how a PUT method affects the state |
---|
755 | of an origin server beyond what can be expressed by the intent of |
---|
756 | the user agent request and the semantics of the origin server response. |
---|
757 | It does not define what a resource might be, in any sense of that |
---|
758 | word, beyond the interface provided via HTTP. It does not define |
---|
759 | how resource state is "stored", nor how such storage might change |
---|
760 | as a result of a change in resource state, nor how the origin server |
---|
761 | translates resource state into representations. Generally speaking, |
---|
762 | all implementation details behind the resource interface are |
---|
763 | intentionally hidden by the server. |
---|
764 | </t> |
---|
765 | <t> |
---|
766 | The fundamental difference between the POST and PUT methods is |
---|
767 | highlighted by the different intent for the target resource. |
---|
768 | The target resource in a POST request is intended to handle the |
---|
769 | enclosed representation as a data-accepting process, such as for |
---|
770 | a gateway to some other protocol or a document that accepts annotations. |
---|
771 | In contrast, the target resource in a PUT request is intended to |
---|
772 | take the enclosed representation as a new or replacement value. |
---|
773 | Hence, the intent of PUT is idempotent and visible to intermediaries, |
---|
774 | even though the exact effect is only known by the origin server. |
---|
775 | </t> |
---|
776 | <t> |
---|
777 | Proper interpretation of a PUT request presumes that the user agent |
---|
778 | knows what target resource is desired. A service that is intended |
---|
779 | to select a proper URI on behalf of the client, after receiving |
---|
780 | a state-changing request, &SHOULD; be implemented using the POST |
---|
781 | method rather than PUT. If the origin server will not make the |
---|
782 | requested PUT state change to the target resource and instead |
---|
783 | wishes to have it applied to a different resource, such as when the |
---|
784 | resource has been moved to a different URI, then the origin server |
---|
785 | &MUST; send a 301 (Moved Permanently) response; the user agent &MAY; |
---|
786 | then make its own decision regarding whether or not to redirect the |
---|
787 | request. |
---|
788 | </t> |
---|
789 | <t> |
---|
790 | A PUT request applied to the target resource &MAY; have side-effects |
---|
791 | on other resources. For example, an article might have a URI for |
---|
792 | identifying "the current version" (a resource) which is separate |
---|
793 | from the URIs identifying each particular version (different |
---|
794 | resources that at one point shared the same state as the current version |
---|
795 | resource). A successful PUT request on "the current version" URI might |
---|
796 | therefore create a new version resource in addition to changing the |
---|
797 | state of the target resource, and might also cause links to be added |
---|
798 | between the related resources. |
---|
799 | </t> |
---|
800 | <t> |
---|
801 | An origin server &SHOULD; reject any PUT request that contains a |
---|
802 | Content-Range header field, since it might be misinterpreted as |
---|
803 | partial content (or might be partial content that is being mistakenly |
---|
804 | PUT as a full representation). Partial content updates are |
---|
805 | possible by targeting a separately identified resource with state |
---|
806 | that overlaps a portion of the larger resource, or by using a |
---|
807 | different method that has been specifically defined for partial |
---|
808 | updates (for example, the PATCH method defined in |
---|
809 | <xref target="RFC5789"/>). |
---|
810 | </t> |
---|
811 | <t> |
---|
812 | Responses to the PUT method are not cacheable. If a PUT request passes |
---|
813 | through a cache that has one or more stored responses for the effective |
---|
814 | request URI, those stored responses will be invalidated (see |
---|
815 | &p6-invalid;). |
---|
816 | </t> |
---|
817 | </section> |
---|
818 | |
---|
819 | <section title="DELETE" anchor="DELETE"> |
---|
820 | <iref primary="true" item="DELETE method" x:for-anchor=""/> |
---|
821 | <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> |
---|
822 | <t> |
---|
823 | The DELETE method requests that the origin server delete the target |
---|
824 | resource. This method &MAY; be overridden by |
---|
825 | human intervention (or other means) on the origin server. The client cannot |
---|
826 | be guaranteed that the operation has been carried out, even if the |
---|
827 | status code returned from the origin server indicates that the action |
---|
828 | has been completed successfully. However, the server &SHOULD-NOT; |
---|
829 | indicate success unless, at the time the response is given, it |
---|
830 | intends to delete the resource or move it to an inaccessible |
---|
831 | location. |
---|
832 | </t> |
---|
833 | <t> |
---|
834 | A successful response &SHOULD; be 200 (OK) if the response includes an |
---|
835 | representation describing the status, 202 (Accepted) if the action has not |
---|
836 | yet been enacted, or 204 (No Content) if the action has been enacted |
---|
837 | but the response does not include a representation. |
---|
838 | </t> |
---|
839 | <t> |
---|
840 | Bodies on DELETE requests have no defined semantics. Note that sending a body |
---|
841 | on a DELETE request might cause some existing implementations to reject the |
---|
842 | request. |
---|
843 | </t> |
---|
844 | <t> |
---|
845 | Responses to the DELETE method are not cacheable. If a DELETE request |
---|
846 | passes through a cache that has one or more stored responses for the |
---|
847 | effective request URI, those stored responses will be invalidated (see |
---|
848 | &p6-invalid;). |
---|
849 | </t> |
---|
850 | </section> |
---|
851 | |
---|
852 | <section title="TRACE" anchor="TRACE"> |
---|
853 | <rdf:Description> |
---|
854 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
855 | </rdf:Description> |
---|
856 | <iref primary="true" item="TRACE method" x:for-anchor=""/> |
---|
857 | <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/> |
---|
858 | <t> |
---|
859 | The TRACE method requests a remote, application-layer loop-back |
---|
860 | of the request message. The final recipient of the request |
---|
861 | &SHOULD; reflect the message received back to the client as the |
---|
862 | message body of a 200 (OK) response. The final recipient is either the |
---|
863 | origin server or the first proxy to receive a Max-Forwards |
---|
864 | value of zero (0) in the request (see <xref target="header.max-forwards"/>). |
---|
865 | A TRACE request &MUST-NOT; include a message body. |
---|
866 | </t> |
---|
867 | <t> |
---|
868 | TRACE allows the client to see what is being received at the other |
---|
869 | end of the request chain and use that data for testing or diagnostic |
---|
870 | information. The value of the Via header field (&header-via;) is of |
---|
871 | particular interest, since it acts as a trace of the request chain. |
---|
872 | Use of the Max-Forwards header field allows the client to limit the |
---|
873 | length of the request chain, which is useful for testing a chain of |
---|
874 | proxies forwarding messages in an infinite loop. |
---|
875 | </t> |
---|
876 | <t> |
---|
877 | If the request is valid, the response &SHOULD; have a Content-Type of |
---|
878 | "message/http" (see &media-type-message-http;) and contain a message body |
---|
879 | that encloses a copy of the entire request message. |
---|
880 | Responses to the TRACE method are not cacheable. |
---|
881 | </t> |
---|
882 | </section> |
---|
883 | |
---|
884 | <section title="CONNECT" anchor="CONNECT"> |
---|
885 | <iref primary="true" item="CONNECT method" x:for-anchor=""/> |
---|
886 | <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> |
---|
887 | <t> |
---|
888 | The CONNECT method requests that the proxy establish a tunnel |
---|
889 | to the request-target and, if successful, thereafter restrict its behavior |
---|
890 | to blind forwarding of packets until the connection is closed. |
---|
891 | </t> |
---|
892 | <t> |
---|
893 | When using CONNECT, the request-target &MUST; use the authority form |
---|
894 | (&request-target;); i.e., the request-target consists of only the |
---|
895 | host name and port number of the tunnel destination, separated by a colon. |
---|
896 | For example, |
---|
897 | </t> |
---|
898 | <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> |
---|
899 | CONNECT server.example.com:80 HTTP/1.1 |
---|
900 | Host: server.example.com:80 |
---|
901 | |
---|
902 | </artwork></figure> |
---|
903 | <t> |
---|
904 | Any successful (2xx) response to a CONNECT request indicates that the |
---|
905 | proxy has established a connection to the requested host and port, |
---|
906 | and has switched to tunneling the current connection to that server |
---|
907 | connection. |
---|
908 | The tunneled data from the server begins immediately after the blank line |
---|
909 | that concludes the successful response's header block. |
---|
910 | A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length |
---|
911 | header fields in a successful response. |
---|
912 | A client &MUST; ignore any Content-Length or Transfer-Encoding header |
---|
913 | fields received in a successful response. |
---|
914 | </t> |
---|
915 | <t> |
---|
916 | Any response other than a successful response indicates that the tunnel |
---|
917 | has not yet been formed and that the connection remains governed by HTTP. |
---|
918 | </t> |
---|
919 | <t> |
---|
920 | Proxy authentication might be used to establish the |
---|
921 | authority to create a tunnel: |
---|
922 | </t> |
---|
923 | <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> |
---|
924 | CONNECT server.example.com:80 HTTP/1.1 |
---|
925 | Host: server.example.com:80 |
---|
926 | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
---|
927 | |
---|
928 | </artwork></figure> |
---|
929 | <t> |
---|
930 | A message body on a CONNECT request has no defined semantics. Sending a |
---|
931 | body on a CONNECT request might cause existing implementations to reject |
---|
932 | the request. |
---|
933 | </t> |
---|
934 | <t> |
---|
935 | Similar to a pipelined HTTP/1.1 request, data to be tunneled from client |
---|
936 | to server &MAY; be sent immediately after the request (before a response |
---|
937 | is received). The usual caveats also apply: |
---|
938 | data may be discarded if the eventual response is negative, and the |
---|
939 | connection may be reset with no response if more than one TCP segment |
---|
940 | is outstanding. |
---|
941 | </t> |
---|
942 | <t> |
---|
943 | It may be the case that the proxy itself can only reach the requested |
---|
944 | origin server through another proxy. In this case, the first proxy |
---|
945 | &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel |
---|
946 | to the authority. A proxy &MUST-NOT; respond with any 2xx status code |
---|
947 | unless it has either a direct or tunnel connection established to the |
---|
948 | authority. |
---|
949 | </t> |
---|
950 | <t> |
---|
951 | If at any point either one of the peers gets disconnected, any |
---|
952 | outstanding data that came from that peer will be passed to the other |
---|
953 | one, and after that also the other connection will be terminated by |
---|
954 | the proxy. If there is outstanding data to that peer undelivered, |
---|
955 | that data will be discarded. |
---|
956 | </t> |
---|
957 | <t> |
---|
958 | An origin server which receives a CONNECT request for itself &MAY; |
---|
959 | respond with a 2xx status code to indicate that a connection is |
---|
960 | established. However, most origin servers do not implement CONNECT. |
---|
961 | </t> |
---|
962 | </section> |
---|
963 | </section> |
---|
964 | |
---|
965 | </section> |
---|
966 | |
---|
967 | <section title="Header Fields" anchor="header.fields"> |
---|
968 | <t> |
---|
969 | Header fields are key value pairs that can be used to communicate data about |
---|
970 | the message, its payload, the target resource, or about the connection |
---|
971 | itself (i.e., control data). See &header-fields; for a general definition |
---|
972 | of their syntax. |
---|
973 | </t> |
---|
974 | |
---|
975 | <section title="Considerations for Creating Header Fields" anchor="considerations.for.creating.header.fields"> |
---|
976 | <t> |
---|
977 | New header fields are registered using the procedures described in |
---|
978 | <xref target="RFC3864"/>. |
---|
979 | </t> |
---|
980 | <t> |
---|
981 | The requirements for header field names are defined in |
---|
982 | <xref target="RFC3864" x:fmt="of" x:sec="4.1"/>. Authors of specifications |
---|
983 | defining new fields are advised to keep the name as short as practical, and |
---|
984 | not to prefix them with "X-" if they are to be registered (either |
---|
985 | immediately or in the future). |
---|
986 | </t> |
---|
987 | <t> |
---|
988 | New header field values typically have their syntax defined using ABNF |
---|
989 | (<xref target="RFC5234"/>), using the extension defined in &abnf-extension; |
---|
990 | as necessary, and are usually constrained to the range of ASCII characters. |
---|
991 | Header fields needing a greater range of characters can use an encoding |
---|
992 | such as the one defined in <xref target="RFC5987"/>. |
---|
993 | </t> |
---|
994 | <t> |
---|
995 | Because commas (",") are used as a generic delimiter between field-values, |
---|
996 | they need to be treated with care if they are allowed in the field-value's |
---|
997 | payload. Typically, components that might contain a comma are protected with |
---|
998 | double-quotes using the quoted-string ABNF production (&field-components;). |
---|
999 | </t> |
---|
1000 | <t> |
---|
1001 | For example, a textual date and a URI (either of which might contain a comma) |
---|
1002 | could be safely carried in field-values like these: |
---|
1003 | </t> |
---|
1004 | <figure><artwork type="example"> |
---|
1005 | Example-URI-Field: "http://example.com/a.html,foo", |
---|
1006 | "http://without-a-comma.example.com/" |
---|
1007 | Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" |
---|
1008 | </artwork></figure> |
---|
1009 | <t> |
---|
1010 | Note that double quote delimiters almost always are used with the |
---|
1011 | quoted-string production; using a different syntax inside double quotes |
---|
1012 | will likely cause unnecessary confusion. |
---|
1013 | </t> |
---|
1014 | <t> |
---|
1015 | Many header fields use a format including (case-insensitively) named |
---|
1016 | parameters (for instance, Content-Type, defined in &header-content-type;). |
---|
1017 | Allowing both unquoted (token) and quoted (quoted-string) syntax for the |
---|
1018 | parameter value enables recipients to use existing parser components. When |
---|
1019 | allowing both forms, the meaning of a parameter value ought to be |
---|
1020 | independent of the syntax used for it (for an example, see the notes on |
---|
1021 | parameter handling for media types in &media-types;). |
---|
1022 | </t> |
---|
1023 | <t> |
---|
1024 | Authors of specifications defining new header fields are advised to consider |
---|
1025 | documenting: |
---|
1026 | <list style="symbols"> |
---|
1027 | <x:lt> |
---|
1028 | <t>Whether the field is a single value, or whether it can be a list |
---|
1029 | (delimited by commas; see &header-fields;).</t> |
---|
1030 | <t>If it does not use the list syntax, document how to treat messages |
---|
1031 | where the header field occurs multiple times (a sensible default would |
---|
1032 | be to ignore the header field, but this might not always be the right |
---|
1033 | choice).</t> |
---|
1034 | <t>Note that intermediaries and software libraries might combine |
---|
1035 | multiple header field instances into a single one, despite the header |
---|
1036 | field not allowing this. A robust format enables recipients to discover |
---|
1037 | these situations (good example: "Content-Type", as the comma can only |
---|
1038 | appear inside quoted strings; bad example: "Location", as a comma can |
---|
1039 | occur inside a URI).</t> |
---|
1040 | </x:lt> |
---|
1041 | <x:lt><t>Under what conditions the header field can be used; e.g., only in |
---|
1042 | responses or requests, in all messages, only on responses to a particular |
---|
1043 | request method.</t></x:lt> |
---|
1044 | <x:lt><t>Whether it is appropriate to list the field-name in the Connection header |
---|
1045 | (i.e., if the header is to be hop-by-hop, see &header-connection;).</t></x:lt> |
---|
1046 | <x:lt><t>Under what conditions intermediaries are allowed to modify the header |
---|
1047 | field's value, insert or delete it.</t></x:lt> |
---|
1048 | <x:lt><t>How the header might interact with caching (see <xref target="Part6"/>).</t></x:lt> |
---|
1049 | <x:lt><t>Whether the header field is useful or allowable in trailers (see |
---|
1050 | &chunked-encoding;).</t></x:lt> |
---|
1051 | <x:lt><t>Whether the header field should be preserved across redirects.</t></x:lt> |
---|
1052 | </list> |
---|
1053 | </t> |
---|
1054 | </section> |
---|
1055 | |
---|
1056 | <section title="Request Header Fields" anchor="request.header.fields"> |
---|
1057 | <x:anchor-alias value="request-header"/> |
---|
1058 | <t> |
---|
1059 | The request header fields allow the client to pass additional |
---|
1060 | information about the request, and about the client itself, to the |
---|
1061 | server. These fields act as request modifiers, with semantics |
---|
1062 | equivalent to the parameters on a programming language method |
---|
1063 | invocation. |
---|
1064 | </t> |
---|
1065 | <texttable align="left"> |
---|
1066 | <ttcol>Header Field Name</ttcol> |
---|
1067 | <ttcol>Defined in...</ttcol> |
---|
1068 | |
---|
1069 | <c>Accept</c> <c>&header-accept;</c> |
---|
1070 | <c>Accept-Charset</c> <c>&header-accept-charset;</c> |
---|
1071 | <c>Accept-Encoding</c> <c>&header-accept-encoding;</c> |
---|
1072 | <c>Accept-Language</c> <c>&header-accept-language;</c> |
---|
1073 | <c>Authorization</c> <c>&header-authorization;</c> |
---|
1074 | <c>Expect</c> <c><xref target="header.expect"/></c> |
---|
1075 | <c>From</c> <c><xref target="header.from"/></c> |
---|
1076 | <c>Host</c> <c>&header-host;</c> |
---|
1077 | <c>If-Match</c> <c>&header-if-match;</c> |
---|
1078 | <c>If-Modified-Since</c> <c>&header-if-modified-since;</c> |
---|
1079 | <c>If-None-Match</c> <c>&header-if-none-match;</c> |
---|
1080 | <c>If-Range</c> <c>&header-if-range;</c> |
---|
1081 | <c>If-Unmodified-Since</c> <c>&header-if-unmodified-since;</c> |
---|
1082 | <c>Max-Forwards</c> <c><xref target="header.max-forwards"/></c> |
---|
1083 | <c>Proxy-Authorization</c> <c>&header-proxy-authorization;</c> |
---|
1084 | <c>Range</c> <c>&header-range;</c> |
---|
1085 | <c>Referer</c> <c><xref target="header.referer"/></c> |
---|
1086 | <c>TE</c> <c>&header-te;</c> |
---|
1087 | <c>User-Agent</c> <c><xref target="header.user-agent"/></c> |
---|
1088 | </texttable> |
---|
1089 | </section> |
---|
1090 | |
---|
1091 | <section title="Response Header Fields" anchor="response.header.fields"> |
---|
1092 | <x:anchor-alias value="response-header"/> |
---|
1093 | <t> |
---|
1094 | The response header fields allow the server to pass additional |
---|
1095 | information about the response which cannot be placed in the status-line. |
---|
1096 | These header fields give information about the server and about |
---|
1097 | further access to the target resource (&effective-request-uri;). |
---|
1098 | </t> |
---|
1099 | <texttable align="left"> |
---|
1100 | <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol> |
---|
1101 | |
---|
1102 | <c>Accept-Ranges</c> <c>&header-accept-ranges;</c> |
---|
1103 | <c>Age</c> <c>&header-age;</c> |
---|
1104 | <c>Allow</c> <c><xref target="header.allow"/></c> |
---|
1105 | <c>Date</c> <c><xref target="header.date"/></c> |
---|
1106 | <c>ETag</c> <c>&header-etag;</c> |
---|
1107 | <c>Location</c> <c><xref target="header.location"/></c> |
---|
1108 | <c>Proxy-Authenticate</c> <c>&header-proxy-authenticate;</c> |
---|
1109 | <c>Retry-After</c> <c><xref target="header.retry-after"/></c> |
---|
1110 | <c>Server</c> <c><xref target="header.server"/></c> |
---|
1111 | <c>Vary</c> <c>&header-vary;</c> |
---|
1112 | <c>WWW-Authenticate</c> <c>&header-www-authenticate;</c> |
---|
1113 | </texttable> |
---|
1114 | </section> |
---|
1115 | |
---|
1116 | </section> |
---|
1117 | |
---|
1118 | <section title="Status Codes" anchor="status.codes"> |
---|
1119 | <t> |
---|
1120 | The status-code element is a 3-digit integer result code of the attempt to |
---|
1121 | understand and satisfy the request. |
---|
1122 | </t> |
---|
1123 | <t> |
---|
1124 | HTTP status codes are extensible. HTTP applications are not required |
---|
1125 | to understand the meaning of all registered status codes, though such |
---|
1126 | understanding is obviously desirable. However, applications &MUST; |
---|
1127 | understand the class of any status code, as indicated by the first |
---|
1128 | digit, and treat any unrecognized response as being equivalent to the |
---|
1129 | x00 status code of that class, with the exception that an |
---|
1130 | unrecognized response &MUST-NOT; be cached. For example, if an |
---|
1131 | unrecognized status code of 431 is received by the client, it can |
---|
1132 | safely assume that there was something wrong with its request and |
---|
1133 | treat the response as if it had received a 400 status code. In such |
---|
1134 | cases, user agents &SHOULD; present to the user the representation enclosed |
---|
1135 | with the response, since that representation is likely to include human-readable |
---|
1136 | information which will explain the unusual status. |
---|
1137 | </t> |
---|
1138 | <t> |
---|
1139 | The first digit of the status-code defines the class of response. The |
---|
1140 | last two digits do not have any categorization role. There are 5 |
---|
1141 | values for the first digit: |
---|
1142 | <list style="symbols"> |
---|
1143 | <t> |
---|
1144 | 1xx: Informational - Request received, continuing process |
---|
1145 | </t> |
---|
1146 | <t> |
---|
1147 | 2xx: Success - The action was successfully received, |
---|
1148 | understood, and accepted |
---|
1149 | </t> |
---|
1150 | <t> |
---|
1151 | 3xx: Redirection - Further action needs to be taken in order to |
---|
1152 | complete the request |
---|
1153 | </t> |
---|
1154 | <t> |
---|
1155 | 4xx: Client Error - The request contains bad syntax or cannot |
---|
1156 | be fulfilled |
---|
1157 | </t> |
---|
1158 | <t> |
---|
1159 | 5xx: Server Error - The server failed to fulfill an apparently |
---|
1160 | valid request |
---|
1161 | </t> |
---|
1162 | </list> |
---|
1163 | </t> |
---|
1164 | <t> |
---|
1165 | For most status codes the response can carry a payload, in which case a |
---|
1166 | Content-Type header field indicates the payload's media type |
---|
1167 | (&header-content-type;). |
---|
1168 | </t> |
---|
1169 | |
---|
1170 | <section title="Overview of Status Codes" anchor="overview.of.status.codes"> |
---|
1171 | <t> |
---|
1172 | The status codes listed below are defined in this specification, |
---|
1173 | &p4-status-codes;, &p5-status-codes;, and &p7-status-codes;. |
---|
1174 | The reason phrases listed here are only recommendations — they can be |
---|
1175 | replaced by local equivalents without affecting the protocol. |
---|
1176 | </t> |
---|
1177 | <texttable align="left"> |
---|
1178 | <ttcol>status-code</ttcol> |
---|
1179 | <ttcol>reason-phrase</ttcol> |
---|
1180 | <ttcol>Defined in...</ttcol> |
---|
1181 | |
---|
1182 | <c>100</c> <c>Continue</c> <c><xref target="status.100"/></c> |
---|
1183 | <c>101</c> <c>Switching Protocols</c> <c><xref target="status.101"/></c> |
---|
1184 | |
---|
1185 | <c>200</c> <c>OK</c> <c><xref target="status.200"/></c> |
---|
1186 | <c>201</c> <c>Created</c> <c><xref target="status.201"/></c> |
---|
1187 | <c>202</c> <c>Accepted</c> <c><xref target="status.202"/></c> |
---|
1188 | <c>203</c> <c>Non-Authoritative Information</c> <c><xref target="status.203"/></c> |
---|
1189 | <c>204</c> <c>No Content</c> <c><xref target="status.204"/></c> |
---|
1190 | <c>205</c> <c>Reset Content</c> <c><xref target="status.205"/></c> |
---|
1191 | <c>206</c> <c>Partial Content</c> <c anchor="status.206">&status-206;</c> |
---|
1192 | |
---|
1193 | <c>300</c> <c>Multiple Choices</c> <c><xref target="status.300"/></c> |
---|
1194 | <c>301</c> <c>Moved Permanently</c> <c><xref target="status.301"/></c> |
---|
1195 | <c>302</c> <c>Found</c> <c><xref target="status.302"/></c> |
---|
1196 | <c>303</c> <c>See Other</c> <c><xref target="status.303"/></c> |
---|
1197 | <c>304</c> <c>Not Modified</c> <c anchor="status.304">&status-304;</c> |
---|
1198 | <c>305</c> <c>Use Proxy</c> <c><xref target="status.305"/></c> |
---|
1199 | <c>307</c> <c>Temporary Redirect</c> <c><xref target="status.307"/></c> |
---|
1200 | |
---|
1201 | <c>400</c> <c>Bad Request</c> <c><xref target="status.400"/></c> |
---|
1202 | <c>401</c> <c>Unauthorized</c> <c anchor="status.401">&status-401;</c> |
---|
1203 | <c>402</c> <c>Payment Required</c> <c><xref target="status.402"/></c> |
---|
1204 | <c>403</c> <c>Forbidden</c> <c><xref target="status.403"/></c> |
---|
1205 | <c>404</c> <c>Not Found</c> <c><xref target="status.404"/></c> |
---|
1206 | <c>405</c> <c>Method Not Allowed</c> <c><xref target="status.405"/></c> |
---|
1207 | <c>406</c> <c>Not Acceptable</c> <c><xref target="status.406"/></c> |
---|
1208 | <c>407</c> <c>Proxy Authentication Required</c> <c anchor="status.407">&status-407;</c> |
---|
1209 | <c>408</c> <c>Request Time-out</c> <c><xref target="status.408"/></c> |
---|
1210 | <c>409</c> <c>Conflict</c> <c><xref target="status.409"/></c> |
---|
1211 | <c>410</c> <c>Gone</c> <c><xref target="status.410"/></c> |
---|
1212 | <c>411</c> <c>Length Required</c> <c><xref target="status.411"/></c> |
---|
1213 | <c>412</c> <c>Precondition Failed</c> <c anchor="status.412">&status-412;</c> |
---|
1214 | <c>413</c> <c>Request Representation Too Large</c> <c><xref target="status.413"/></c> |
---|
1215 | <c>414</c> <c>URI Too Long</c> <c><xref target="status.414"/></c> |
---|
1216 | <c>415</c> <c>Unsupported Media Type</c> <c><xref target="status.415"/></c> |
---|
1217 | <c>416</c> <c>Requested range not satisfiable</c> <c anchor="status.416">&status-416;</c> |
---|
1218 | <c>417</c> <c>Expectation Failed</c> <c><xref target="status.417"/></c> |
---|
1219 | <c>426</c> <c>Upgrade Required</c> <c><xref target="status.426"/></c> |
---|
1220 | |
---|
1221 | <c>500</c> <c>Internal Server Error</c> <c><xref target="status.500"/></c> |
---|
1222 | <c>501</c> <c>Not Implemented</c> <c><xref target="status.501"/></c> |
---|
1223 | <c>502</c> <c>Bad Gateway</c> <c><xref target="status.502"/></c> |
---|
1224 | <c>503</c> <c>Service Unavailable</c> <c><xref target="status.503"/></c> |
---|
1225 | <c>504</c> <c>Gateway Time-out</c> <c><xref target="status.504"/></c> |
---|
1226 | <c>505</c> <c>HTTP Version not supported</c> <c><xref target="status.505"/></c> |
---|
1227 | </texttable> |
---|
1228 | <t> |
---|
1229 | Note that this list is not exhaustive — it does not include |
---|
1230 | extension status codes defined in other specifications. |
---|
1231 | </t> |
---|
1232 | </section> |
---|
1233 | |
---|
1234 | <section title="Status Code Registry" anchor="status.code.registry"> |
---|
1235 | <t> |
---|
1236 | The HTTP Status Code Registry defines the name space for the status-code |
---|
1237 | token in the status-line of an HTTP response. |
---|
1238 | </t> |
---|
1239 | <t> |
---|
1240 | Values to be added to this name space require IETF Review |
---|
1241 | (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). |
---|
1242 | </t> |
---|
1243 | <t> |
---|
1244 | The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>. |
---|
1245 | </t> |
---|
1246 | |
---|
1247 | <section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes"> |
---|
1248 | <t> |
---|
1249 | When it is necessary to express new semantics for a HTTP response that |
---|
1250 | aren't specific to a single application or media type, and currently defined |
---|
1251 | status codes are inadequate, a new status code can be registered. |
---|
1252 | </t> |
---|
1253 | <t> |
---|
1254 | HTTP status codes are generic; that is, they are potentially applicable to |
---|
1255 | any resource, not just one particular media type, "type" of resource, or |
---|
1256 | application. As such, it is preferred that new HTTP status codes be |
---|
1257 | registered in a document that isn't specific to a single application, so |
---|
1258 | that this is clear. |
---|
1259 | </t> |
---|
1260 | <t> |
---|
1261 | Definitions of new HTTP status codes typically explain the request |
---|
1262 | conditions that produce a response containing the status code (e.g., |
---|
1263 | combinations of request headers and/or method(s)), along with any |
---|
1264 | interactions with response headers (e.g., those that are required, those |
---|
1265 | that modify the semantics of the response). |
---|
1266 | </t> |
---|
1267 | <t> |
---|
1268 | New HTTP status codes are required to fall under one of the categories |
---|
1269 | defined in <xref target="status.codes"/>. To allow existing parsers to |
---|
1270 | properly handle them, new status codes cannot disallow a response body, |
---|
1271 | although they can mandate a zero-length response body. They can require the |
---|
1272 | presence of one or more particular HTTP response header(s). |
---|
1273 | </t> |
---|
1274 | <t> |
---|
1275 | Likewise, their definitions can specify that caches are allowed to use |
---|
1276 | heuristics to determine their freshness (see &caching;; by default, it is |
---|
1277 | not allowed), and can define how to determine the resource which they |
---|
1278 | carry a representation for (see <xref |
---|
1279 | target="identifying.response.associated.with.representation"/>; by default, |
---|
1280 | it is anonymous). |
---|
1281 | </t> |
---|
1282 | </section> |
---|
1283 | |
---|
1284 | </section> |
---|
1285 | |
---|
1286 | <section title="Informational 1xx" anchor="status.1xx"> |
---|
1287 | <t> |
---|
1288 | This class of status code indicates a provisional response, |
---|
1289 | consisting only of the status-line and optional header fields, and is |
---|
1290 | terminated by an empty line. There are no required header fields for this |
---|
1291 | class of status code. Since HTTP/1.0 did not define any 1xx status |
---|
1292 | codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client |
---|
1293 | except under experimental conditions. |
---|
1294 | </t> |
---|
1295 | <t> |
---|
1296 | A client &MUST; be prepared to accept one or more 1xx status responses |
---|
1297 | prior to a regular response, even if the client does not expect a 100 |
---|
1298 | (Continue) status message. Unexpected 1xx status responses &MAY; be |
---|
1299 | ignored by a user agent. |
---|
1300 | </t> |
---|
1301 | <t> |
---|
1302 | Proxies &MUST; forward 1xx responses, unless the connection between the |
---|
1303 | proxy and its client has been closed, or unless the proxy itself |
---|
1304 | requested the generation of the 1xx response. (For example, if a |
---|
1305 | proxy adds a "Expect: 100-continue" field when it forwards a request, |
---|
1306 | then it need not forward the corresponding 100 (Continue) |
---|
1307 | response(s).) |
---|
1308 | </t> |
---|
1309 | |
---|
1310 | <section title="100 Continue" anchor="status.100"> |
---|
1311 | <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/> |
---|
1312 | <iref primary="true" item="Status Codes" subitem="100 Continue" x:for-anchor=""/> |
---|
1313 | <t> |
---|
1314 | The client &SHOULD; continue with its request. This interim response is |
---|
1315 | used to inform the client that the initial part of the request has |
---|
1316 | been received and has not yet been rejected by the server. The client |
---|
1317 | &SHOULD; continue by sending the remainder of the request or, if the |
---|
1318 | request has already been completed, ignore this response. The server |
---|
1319 | &MUST; send a final response after the request has been completed. See |
---|
1320 | &use100; for detailed discussion of the use and handling of this |
---|
1321 | status code. |
---|
1322 | </t> |
---|
1323 | </section> |
---|
1324 | |
---|
1325 | <section title="101 Switching Protocols" anchor="status.101"> |
---|
1326 | <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/> |
---|
1327 | <iref primary="true" item="Status Codes" subitem="101 Switching Protocols" x:for-anchor=""/> |
---|
1328 | <t> |
---|
1329 | The server understands and is willing to comply with the client's |
---|
1330 | request, via the Upgrade message header field (&header-upgrade;), for a |
---|
1331 | change in the application protocol being used on this connection. The |
---|
1332 | server will switch protocols to those defined by the response's |
---|
1333 | Upgrade header field immediately after the empty line which |
---|
1334 | terminates the 101 response. |
---|
1335 | </t> |
---|
1336 | <t> |
---|
1337 | The protocol &SHOULD; be switched only when it is advantageous to do |
---|
1338 | so. For example, switching to a newer version of HTTP is advantageous |
---|
1339 | over older versions, and switching to a real-time, synchronous |
---|
1340 | protocol might be advantageous when delivering resources that use |
---|
1341 | such features. |
---|
1342 | </t> |
---|
1343 | </section> |
---|
1344 | </section> |
---|
1345 | |
---|
1346 | <section title="Successful 2xx" anchor="status.2xx"> |
---|
1347 | <t> |
---|
1348 | This class of status code indicates that the client's request was |
---|
1349 | successfully received, understood, and accepted. |
---|
1350 | </t> |
---|
1351 | |
---|
1352 | <section title="200 OK" anchor="status.200"> |
---|
1353 | <iref primary="true" item="200 OK (status code)" x:for-anchor=""/> |
---|
1354 | <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/> |
---|
1355 | <t> |
---|
1356 | The request has succeeded. The payload returned with the response |
---|
1357 | is dependent on the method used in the request, for example: |
---|
1358 | <list style="hanging"> |
---|
1359 | <t hangText="GET"> |
---|
1360 | a representation of the target resource is sent in the response; |
---|
1361 | </t> |
---|
1362 | <t hangText="HEAD"> |
---|
1363 | the same representation as GET, except without the message body; |
---|
1364 | </t> |
---|
1365 | <t hangText="POST"> |
---|
1366 | a representation describing or containing the result of the action; |
---|
1367 | </t> |
---|
1368 | <t hangText="TRACE"> |
---|
1369 | a representation containing the request message as received by the |
---|
1370 | end server. |
---|
1371 | </t> |
---|
1372 | </list> |
---|
1373 | </t> |
---|
1374 | <t> |
---|
1375 | Caches &MAY; use a heuristic (see &p6-heuristic;) to determine |
---|
1376 | freshness for 200 responses. |
---|
1377 | </t> |
---|
1378 | </section> |
---|
1379 | |
---|
1380 | <section title="201 Created" anchor="status.201"> |
---|
1381 | <iref primary="true" item="201 Created (status code)" x:for-anchor=""/> |
---|
1382 | <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/> |
---|
1383 | <t> |
---|
1384 | The request has been fulfilled and has resulted in a new resource being |
---|
1385 | created. |
---|
1386 | </t> |
---|
1387 | <t> |
---|
1388 | The newly created resource is typically linked to from the response payload, |
---|
1389 | with the most relevant URI also being carried in the Location header field. |
---|
1390 | If the newly created resource's URI is the same as the Effective Request URI, |
---|
1391 | this information can be omitted (e.g., in the case of a response to a PUT |
---|
1392 | request). |
---|
1393 | </t> |
---|
1394 | <t> |
---|
1395 | The origin server &MUST; create the resource before returning the 201 status |
---|
1396 | code. If the action cannot be carried out immediately, the server &SHOULD; |
---|
1397 | respond with 202 (Accepted) response instead. |
---|
1398 | </t> |
---|
1399 | <t> |
---|
1400 | A 201 response &MAY; contain an ETag response header field indicating |
---|
1401 | the current value of the entity-tag for the representation of the resource |
---|
1402 | just created (see &header-etag;). |
---|
1403 | </t> |
---|
1404 | </section> |
---|
1405 | |
---|
1406 | <section title="202 Accepted" anchor="status.202"> |
---|
1407 | <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/> |
---|
1408 | <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/> |
---|
1409 | <t> |
---|
1410 | The request has been accepted for processing, but the processing has |
---|
1411 | not been completed. The request might or might not eventually be |
---|
1412 | acted upon, as it might be disallowed when processing actually takes |
---|
1413 | place. There is no facility for re-sending a status code from an |
---|
1414 | asynchronous operation such as this. |
---|
1415 | </t> |
---|
1416 | <t> |
---|
1417 | The 202 response is intentionally non-committal. Its purpose is to |
---|
1418 | allow a server to accept a request for some other process (perhaps a |
---|
1419 | batch-oriented process that is only run once per day) without |
---|
1420 | requiring that the user agent's connection to the server persist |
---|
1421 | until the process is completed. The representation returned with this |
---|
1422 | response &SHOULD; include an indication of the request's current status |
---|
1423 | and either a pointer to a status monitor or some estimate of when the |
---|
1424 | user can expect the request to be fulfilled. |
---|
1425 | </t> |
---|
1426 | </section> |
---|
1427 | |
---|
1428 | <section title="203 Non-Authoritative Information" anchor="status.203"> |
---|
1429 | <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/> |
---|
1430 | <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/> |
---|
1431 | <t> |
---|
1432 | The representation in the response has been transformed or otherwise |
---|
1433 | modified by a transforming proxy (&intermediaries;). Note that the |
---|
1434 | behavior of transforming intermediaries is controlled by the no-transform |
---|
1435 | Cache-Control directive (&header-cache-control;). |
---|
1436 | </t> |
---|
1437 | <t> |
---|
1438 | This status code is only appropriate when the response status code would |
---|
1439 | have been 200 (OK) otherwise. When the status code before transformation |
---|
1440 | would have been different, the 214 Transformation Applied warn-code |
---|
1441 | (&header-warning;) is appropriate. |
---|
1442 | </t> |
---|
1443 | <t> |
---|
1444 | Caches &MAY; use a heuristic (see &p6-heuristic;) to determine |
---|
1445 | freshness for 203 responses. |
---|
1446 | </t> |
---|
1447 | </section> |
---|
1448 | |
---|
1449 | <section title="204 No Content" anchor="status.204"> |
---|
1450 | <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/> |
---|
1451 | <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/> |
---|
1452 | <t> |
---|
1453 | The 204 (No Content) status code indicates that the server has |
---|
1454 | successfully fulfilled the request and that there is no additional |
---|
1455 | content to return in the response payload body. Metadata in the |
---|
1456 | response header fields refer to the target resource and its current |
---|
1457 | representation after the requested action. |
---|
1458 | </t> |
---|
1459 | <t> |
---|
1460 | For example, if a 204 status code is received in response to a PUT |
---|
1461 | request and the response contains an ETag header field, then the PUT |
---|
1462 | was successful and the ETag field-value contains the entity-tag for |
---|
1463 | the new representation of that target resource. |
---|
1464 | </t> |
---|
1465 | <t> |
---|
1466 | The 204 response allows a server to indicate that the action has been |
---|
1467 | successfully applied to the target resource while implying that the |
---|
1468 | user agent &SHOULD-NOT; traverse away from its current "document view" |
---|
1469 | (if any). The server assumes that the user agent will provide some |
---|
1470 | indication of the success to its user, in accord with its own interface, |
---|
1471 | and apply any new or updated metadata in the response to the active |
---|
1472 | representation. |
---|
1473 | </t> |
---|
1474 | <t> |
---|
1475 | For example, a 204 status code is commonly used with document editing |
---|
1476 | interfaces corresponding to a "save" action, such that the document |
---|
1477 | being saved remains available to the user for editing. It is also |
---|
1478 | frequently used with interfaces that expect automated data transfers |
---|
1479 | to be prevalent, such as within distributed version control systems. |
---|
1480 | </t> |
---|
1481 | <t> |
---|
1482 | The 204 response &MUST-NOT; include a message body, and thus is always |
---|
1483 | terminated by the first empty line after the header fields. |
---|
1484 | </t> |
---|
1485 | </section> |
---|
1486 | |
---|
1487 | <section title="205 Reset Content" anchor="status.205"> |
---|
1488 | <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/> |
---|
1489 | <iref primary="true" item="Status Codes" subitem="205 Reset Content" x:for-anchor=""/> |
---|
1490 | <t> |
---|
1491 | The server has fulfilled the request and the user agent &SHOULD; reset |
---|
1492 | the document view which caused the request to be sent. This response |
---|
1493 | is primarily intended to allow input for actions to take place via |
---|
1494 | user input, followed by a clearing of the form in which the input is |
---|
1495 | given so that the user can easily initiate another input action. |
---|
1496 | </t> |
---|
1497 | <t> |
---|
1498 | The message body included with the response &MUST; be empty. Note that |
---|
1499 | receivers still need to parse the response according to the algorithm defined |
---|
1500 | in &message-body;. |
---|
1501 | </t> |
---|
1502 | </section> |
---|
1503 | </section> |
---|
1504 | |
---|
1505 | <section title="Redirection 3xx" anchor="status.3xx"> |
---|
1506 | <t> |
---|
1507 | This class of status code indicates that further action needs to be |
---|
1508 | taken by the user agent in order to fulfill the request. If the required |
---|
1509 | action involves a subsequent HTTP request, it &MAY; be carried out by the |
---|
1510 | user agent without interaction with the user if and only if the method used |
---|
1511 | in the second request is known to be "safe", as defined in |
---|
1512 | <xref target="safe.methods"/>. |
---|
1513 | </t> |
---|
1514 | <t> |
---|
1515 | There are several types of redirects: |
---|
1516 | <list style="numbers"> |
---|
1517 | <x:lt> |
---|
1518 | <t> |
---|
1519 | Redirects of the request to another URI, either temporarily or |
---|
1520 | permanently. The new URI is specified in the Location header field. |
---|
1521 | In this specification, the status codes 301 (Moved Permanently), |
---|
1522 | 302 (Found), and 307 (Temporary Redirect) fall under this category. |
---|
1523 | </t> |
---|
1524 | </x:lt> |
---|
1525 | <x:lt> |
---|
1526 | <t> |
---|
1527 | Redirection to a new location that represents an indirect response to |
---|
1528 | the request, such as the result of a POST operation to be retrieved |
---|
1529 | with a subsequent GET request. This is status code 303 (See Other). |
---|
1530 | </t> |
---|
1531 | </x:lt> |
---|
1532 | <x:lt> |
---|
1533 | <t> |
---|
1534 | Redirection offering a choice of matching resources for use by |
---|
1535 | agent-driven content negotiation (&agent-driven-negotiation;). This |
---|
1536 | is status code 300 (Multiple Choices). |
---|
1537 | </t> |
---|
1538 | </x:lt> |
---|
1539 | <x:lt> |
---|
1540 | <t> |
---|
1541 | Other kinds of redirection, such as to a cached result (status code 304 |
---|
1542 | (Not Modified), see &status-304;). |
---|
1543 | </t> |
---|
1544 | </x:lt> |
---|
1545 | </list> |
---|
1546 | </t> |
---|
1547 | <x:note> |
---|
1548 | <t> |
---|
1549 | <x:h>Note:</x:h> In HTTP/1.0, only the status codes 301 (Moved Permanently) |
---|
1550 | and 302 (Found) were defined for the first type of redirect, and the second |
---|
1551 | type did not exist at all (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>). |
---|
1552 | However it turned out that web forms using POST expected redirects to change |
---|
1553 | the operation for the subsequent request to retrieval (GET). To address this |
---|
1554 | use case, HTTP/1.1 introduced the second type of redirect with the status |
---|
1555 | code 303 (See Other) (<xref target="RFC2068" x:fmt="," x:sec="10.3.4"/>). |
---|
1556 | As user agents did not change their behavior to maintain backwards |
---|
1557 | compatibility, the first revision of HTTP/1.1 added yet another status code, |
---|
1558 | 307 (Temporary Redirect), for which the backwards compatibility problems did |
---|
1559 | not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>). |
---|
1560 | Over 10 years later, most user agents still do method rewriting for |
---|
1561 | status codes 301 and 302, therefore this specification makes that behavior |
---|
1562 | conformant in case the original request was POST. |
---|
1563 | </t> |
---|
1564 | </x:note> |
---|
1565 | <t> |
---|
1566 | A Location header field on a 3xx response indicates that a client &MAY; |
---|
1567 | automatically redirect to the URI provided; see <xref target="header.location"/>. |
---|
1568 | </t> |
---|
1569 | <t> |
---|
1570 | Note that for methods not known to be "safe", as defined in <xref target="safe.methods"/>, |
---|
1571 | automatic redirection needs to done with care, since the redirect might |
---|
1572 | change the conditions under which the request was issued. |
---|
1573 | </t> |
---|
1574 | <t> |
---|
1575 | Clients &SHOULD; detect and intervene in cyclical redirections (i.e., |
---|
1576 | "infinite" redirection loops). |
---|
1577 | </t> |
---|
1578 | <x:note> |
---|
1579 | <t> |
---|
1580 | <x:h>Note:</x:h> An earlier version of this specification recommended a |
---|
1581 | maximum of five redirections (<xref target="RFC2068" x:fmt="," x:sec="10.3"/>). |
---|
1582 | Content developers need to be aware that some clients might |
---|
1583 | implement such a fixed limitation. |
---|
1584 | </t> |
---|
1585 | </x:note> |
---|
1586 | |
---|
1587 | <section title="300 Multiple Choices" anchor="status.300"> |
---|
1588 | <iref primary="true" item="300 Multiple Choices (status code)" x:for-anchor=""/> |
---|
1589 | <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/> |
---|
1590 | <t> |
---|
1591 | The target resource has more than one |
---|
1592 | representation, each with its own specific location, and agent-driven |
---|
1593 | negotiation information (&content-negotiation;) is being provided so that |
---|
1594 | the user (or user agent) can select a preferred representation by |
---|
1595 | redirecting its request to that location. |
---|
1596 | </t> |
---|
1597 | <t> |
---|
1598 | Unless it was a HEAD request, the response &SHOULD; include a representation |
---|
1599 | containing a list of representation metadata and location(s) from |
---|
1600 | which the user or user agent can choose the one most appropriate. Depending |
---|
1601 | upon the format and the capabilities of |
---|
1602 | the user agent, selection of the most appropriate choice &MAY; be |
---|
1603 | performed automatically. However, this specification does not define |
---|
1604 | any standard for such automatic selection. |
---|
1605 | </t> |
---|
1606 | <t> |
---|
1607 | If the server has a preferred choice of representation, it &SHOULD; |
---|
1608 | include the specific URI for that representation in the Location |
---|
1609 | field; user agents &MAY; use the Location field value for automatic |
---|
1610 | redirection. |
---|
1611 | </t> |
---|
1612 | <t> |
---|
1613 | Caches &MAY; use a heuristic (see &p6-heuristic;) to determine |
---|
1614 | freshness for 300 responses. |
---|
1615 | </t> |
---|
1616 | |
---|
1617 | </section> |
---|
1618 | |
---|
1619 | <section title="301 Moved Permanently" anchor="status.301"> |
---|
1620 | <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/> |
---|
1621 | <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/> |
---|
1622 | <t> |
---|
1623 | The target resource has been assigned a new permanent URI and any |
---|
1624 | future references to this resource &SHOULD; use one of the returned |
---|
1625 | URIs. Clients with link editing capabilities ought to automatically |
---|
1626 | re-link references to the effective request URI to one or more of the new |
---|
1627 | references returned by the server, where possible. |
---|
1628 | </t> |
---|
1629 | <t> |
---|
1630 | Caches &MAY; use a heuristic (see &p6-heuristic;) to determine |
---|
1631 | freshness for 301 responses. |
---|
1632 | </t> |
---|
1633 | <t> |
---|
1634 | The new permanent URI &SHOULD; be given by the Location field in the |
---|
1635 | response. A response payload can contain a short hypertext note with a |
---|
1636 | hyperlink to the new URI(s). |
---|
1637 | </t> |
---|
1638 | <x:note> |
---|
1639 | <t> |
---|
1640 | <x:h>Note:</x:h> For historic reasons, user agents &MAY; change the |
---|
1641 | request method from POST to GET for the subsequent request. If this |
---|
1642 | behavior is undesired, status code 307 (Temporary Redirect) can be used |
---|
1643 | instead. |
---|
1644 | </t> |
---|
1645 | </x:note> |
---|
1646 | </section> |
---|
1647 | |
---|
1648 | <section title="302 Found" anchor="status.302"> |
---|
1649 | <iref primary="true" item="302 Found (status code)" x:for-anchor=""/> |
---|
1650 | <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/> |
---|
1651 | <t> |
---|
1652 | The target resource resides temporarily under a different URI. |
---|
1653 | Since the redirection might be altered on occasion, the client &SHOULD; |
---|
1654 | continue to use the effective request URI for future requests. |
---|
1655 | </t> |
---|
1656 | <t> |
---|
1657 | The temporary URI &SHOULD; be given by the Location field in the |
---|
1658 | response. A response payload can contain a short hypertext note with a |
---|
1659 | hyperlink to the new URI(s). |
---|
1660 | </t> |
---|
1661 | <x:note> |
---|
1662 | <t> |
---|
1663 | <x:h>Note:</x:h> For historic reasons, user agents &MAY; change the |
---|
1664 | request method from POST to GET for the subsequent request. If this |
---|
1665 | behavior is undesired, status code 307 (Temporary Redirect) can be used |
---|
1666 | instead. |
---|
1667 | </t> |
---|
1668 | </x:note> |
---|
1669 | </section> |
---|
1670 | |
---|
1671 | <section title="303 See Other" anchor="status.303"> |
---|
1672 | <iref primary="true" item="303 See Other (status code)" x:for-anchor=""/> |
---|
1673 | <iref primary="true" item="Status Codes" subitem="303 See Other" x:for-anchor=""/> |
---|
1674 | <t> |
---|
1675 | The 303 status code indicates that the server is redirecting the |
---|
1676 | user agent to a different resource, as indicated by a URI in the |
---|
1677 | Location header field, that is intended to provide an indirect |
---|
1678 | response to the original request. In order to satisfy the original |
---|
1679 | request, a user agent &SHOULD; perform a retrieval request using the |
---|
1680 | Location URI (a GET or HEAD request if using HTTP), which |
---|
1681 | may itself be redirected further, and present the eventual result as an |
---|
1682 | answer to the original request. |
---|
1683 | Note that the new URI in the Location header field is not considered |
---|
1684 | equivalent to the effective request URI. |
---|
1685 | </t> |
---|
1686 | <t> |
---|
1687 | This status code is generally applicable to any HTTP method. It is |
---|
1688 | primarily used to allow the output of a POST action to redirect |
---|
1689 | the user agent to a selected resource, since doing so provides the |
---|
1690 | information corresponding to the POST response in a form that |
---|
1691 | can be separately identified, bookmarked, and cached independent |
---|
1692 | of the original request. |
---|
1693 | </t> |
---|
1694 | <t> |
---|
1695 | A 303 response to a GET request indicates that the requested |
---|
1696 | resource does not have a representation of its own that can be |
---|
1697 | transferred by the server over HTTP. The Location URI indicates a |
---|
1698 | resource that is descriptive of the target resource, such that the |
---|
1699 | follow-on representation might be useful to recipients without |
---|
1700 | implying that it adequately represents the target resource. |
---|
1701 | Note that answers to the questions of what can be represented, what |
---|
1702 | representations are adequate, and what might be a useful description |
---|
1703 | are outside the scope of HTTP and thus entirely determined by the |
---|
1704 | URI owner(s). |
---|
1705 | </t> |
---|
1706 | <t> |
---|
1707 | Except for responses to a HEAD request, the representation of a 303 |
---|
1708 | response &SHOULD; contain a short hypertext note with a hyperlink |
---|
1709 | to the Location URI. |
---|
1710 | </t> |
---|
1711 | </section> |
---|
1712 | |
---|
1713 | <section title="305 Use Proxy" anchor="status.305"> |
---|
1714 | <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/> |
---|
1715 | <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/> |
---|
1716 | <t> |
---|
1717 | The 305 status code was defined in a previous version of this specification |
---|
1718 | (see <xref target="changes.from.rfc.2616"/>), and is now deprecated. |
---|
1719 | </t> |
---|
1720 | </section> |
---|
1721 | |
---|
1722 | <section title="306 (Unused)" anchor="status.306"> |
---|
1723 | <iref primary="true" item="306 (Unused) (status code)" x:for-anchor=""/> |
---|
1724 | <iref primary="true" item="Status Codes" subitem="306 (Unused)" x:for-anchor=""/> |
---|
1725 | <t> |
---|
1726 | The 306 status code was used in a previous version of the |
---|
1727 | specification, is no longer used, and the code is reserved. |
---|
1728 | </t> |
---|
1729 | </section> |
---|
1730 | |
---|
1731 | <section title="307 Temporary Redirect" anchor="status.307"> |
---|
1732 | <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/> |
---|
1733 | <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/> |
---|
1734 | <t> |
---|
1735 | The target resource resides temporarily under a different URI. |
---|
1736 | Since the redirection can change over time, the client &SHOULD; |
---|
1737 | continue to use the effective request URI for future requests. |
---|
1738 | </t> |
---|
1739 | <t> |
---|
1740 | The temporary URI &SHOULD; be given by the Location field in the |
---|
1741 | response. A response payload can contain a short hypertext note with a |
---|
1742 | hyperlink to the new URI(s). |
---|
1743 | </t> |
---|
1744 | <x:note> |
---|
1745 | <t> |
---|
1746 | <x:h>Note:</x:h> This status code is similar to 302 Found, except that |
---|
1747 | it does not allow rewriting the request method from POST to GET. This |
---|
1748 | specification defines no equivalent counterpart for 301 Moved Permanently |
---|
1749 | (<xref target="draft-reschke-http-status-308"/>, however, defines the |
---|
1750 | status code 308 Permanent Redirect for this purpose). |
---|
1751 | </t> |
---|
1752 | </x:note> |
---|
1753 | </section> |
---|
1754 | </section> |
---|
1755 | |
---|
1756 | <section title="Client Error 4xx" anchor="status.4xx"> |
---|
1757 | <t> |
---|
1758 | The 4xx class of status code is intended for cases in which the |
---|
1759 | client seems to have erred. Except when responding to a HEAD request, |
---|
1760 | the server &SHOULD; include a representation containing an explanation of the |
---|
1761 | error situation, and whether it is a temporary or permanent |
---|
1762 | condition. These status codes are applicable to any request method. |
---|
1763 | User agents &SHOULD; display any included representation to the user. |
---|
1764 | </t> |
---|
1765 | |
---|
1766 | <section title="400 Bad Request" anchor="status.400"> |
---|
1767 | <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/> |
---|
1768 | <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/> |
---|
1769 | <t> |
---|
1770 | The server cannot or will not process the request, due to a client error (e.g., |
---|
1771 | malformed syntax). |
---|
1772 | </t> |
---|
1773 | </section> |
---|
1774 | |
---|
1775 | <section title="402 Payment Required" anchor="status.402"> |
---|
1776 | <iref primary="true" item="402 Payment Required (status code)" x:for-anchor=""/> |
---|
1777 | <iref primary="true" item="Status Codes" subitem="402 Payment Required" x:for-anchor=""/> |
---|
1778 | <t> |
---|
1779 | This code is reserved for future use. |
---|
1780 | </t> |
---|
1781 | </section> |
---|
1782 | |
---|
1783 | <section title="403 Forbidden" anchor="status.403"> |
---|
1784 | <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/> |
---|
1785 | <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/> |
---|
1786 | <t> |
---|
1787 | The server understood the request, but refuses to authorize it. Providing |
---|
1788 | different user authentication credentials might be successful, but any |
---|
1789 | credentials that were provided in the request are insufficient. The request |
---|
1790 | &SHOULD-NOT; be repeated with the same credentials. |
---|
1791 | </t> |
---|
1792 | <t> |
---|
1793 | If the request method was not HEAD and the server wishes to make |
---|
1794 | public why the request has not been fulfilled, it &SHOULD; describe the |
---|
1795 | reason for the refusal in the representation. If the server does not wish to |
---|
1796 | make this information available to the client, the status code 404 |
---|
1797 | (Not Found) &MAY; be used instead. |
---|
1798 | </t> |
---|
1799 | </section> |
---|
1800 | |
---|
1801 | <section title="404 Not Found" anchor="status.404"> |
---|
1802 | <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/> |
---|
1803 | <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> |
---|
1804 | <t> |
---|
1805 | The server has not found anything matching the effective request URI. No |
---|
1806 | indication is given of whether the condition is temporary or |
---|
1807 | permanent. The 410 (Gone) status code &SHOULD; be used if the server |
---|
1808 | knows, through some internally configurable mechanism, that an old |
---|
1809 | resource is permanently unavailable and has no forwarding address. |
---|
1810 | This status code is commonly used when the server does not wish to |
---|
1811 | reveal exactly why the request has been refused, or when no other |
---|
1812 | response is applicable. |
---|
1813 | </t> |
---|
1814 | </section> |
---|
1815 | |
---|
1816 | <section title="405 Method Not Allowed" anchor="status.405"> |
---|
1817 | <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/> |
---|
1818 | <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/> |
---|
1819 | <t> |
---|
1820 | The method specified in the request-line is not allowed for the target |
---|
1821 | resource. The response &MUST; include an Allow header field containing a |
---|
1822 | list of valid methods for the requested resource. |
---|
1823 | </t> |
---|
1824 | </section> |
---|
1825 | |
---|
1826 | <section title="406 Not Acceptable" anchor="status.406"> |
---|
1827 | <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/> |
---|
1828 | <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/> |
---|
1829 | <t> |
---|
1830 | The resource identified by the request is only capable of generating |
---|
1831 | response representations which have content characteristics not acceptable |
---|
1832 | according to the Accept and Accept-* header fields sent in the request |
---|
1833 | (see &p3-header-fields;). |
---|
1834 | </t> |
---|
1835 | <t> |
---|
1836 | Unless it was a HEAD request, the response &SHOULD; include a representation |
---|
1837 | containing a list of available representation characteristics and location(s) |
---|
1838 | from which the user or user agent can choose the one most |
---|
1839 | appropriate. Depending upon the format and the |
---|
1840 | capabilities of the user agent, selection of the most appropriate |
---|
1841 | choice &MAY; be performed automatically. However, this specification |
---|
1842 | does not define any standard for such automatic selection. |
---|
1843 | </t> |
---|
1844 | <x:note> |
---|
1845 | <t> |
---|
1846 | <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are |
---|
1847 | not acceptable according to the accept header fields sent in the |
---|
1848 | request. In some cases, this might even be preferable to sending a |
---|
1849 | 406 response. User agents are encouraged to inspect the header fields of |
---|
1850 | an incoming response to determine if it is acceptable. |
---|
1851 | </t> |
---|
1852 | </x:note> |
---|
1853 | <t> |
---|
1854 | If the response could be unacceptable, a user agent &SHOULD; |
---|
1855 | temporarily stop receipt of more data and query the user for a |
---|
1856 | decision on further actions. |
---|
1857 | </t> |
---|
1858 | </section> |
---|
1859 | |
---|
1860 | <section title="408 Request Timeout" anchor="status.408"> |
---|
1861 | <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/> |
---|
1862 | <iref primary="true" item="Status Codes" subitem="408 Request Timeout" x:for-anchor=""/> |
---|
1863 | <t> |
---|
1864 | The client did not produce a request within the time that the server |
---|
1865 | was prepared to wait. The client &MAY; repeat the request without |
---|
1866 | modifications at any later time. |
---|
1867 | </t> |
---|
1868 | </section> |
---|
1869 | |
---|
1870 | <section title="409 Conflict" anchor="status.409"> |
---|
1871 | <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/> |
---|
1872 | <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/> |
---|
1873 | <t> |
---|
1874 | The request could not be completed due to a conflict with the current |
---|
1875 | state of the resource. This code is only allowed in situations where |
---|
1876 | it is expected that the user might be able to resolve the conflict |
---|
1877 | and resubmit the request. The response body &SHOULD; include enough |
---|
1878 | information for the user to recognize the source of the conflict. |
---|
1879 | Ideally, the response representation would include enough information for the |
---|
1880 | user or user agent to fix the problem; however, that might not be |
---|
1881 | possible and is not required. |
---|
1882 | </t> |
---|
1883 | <t> |
---|
1884 | Conflicts are most likely to occur in response to a PUT request. For |
---|
1885 | example, if versioning were being used and the representation being PUT |
---|
1886 | included changes to a resource which conflict with those made by an |
---|
1887 | earlier (third-party) request, the server might use the 409 response |
---|
1888 | to indicate that it can't complete the request. In this case, the |
---|
1889 | response representation would likely contain a list of the differences |
---|
1890 | between the two versions. |
---|
1891 | </t> |
---|
1892 | </section> |
---|
1893 | |
---|
1894 | <section title="410 Gone" anchor="status.410"> |
---|
1895 | <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/> |
---|
1896 | <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/> |
---|
1897 | <t> |
---|
1898 | The target resource is no longer available at the server and no |
---|
1899 | forwarding address is known. This condition is expected to be |
---|
1900 | considered permanent. Clients with link editing capabilities &SHOULD; |
---|
1901 | delete references to the effective request URI after user approval. If the |
---|
1902 | server does not know, or has no facility to determine, whether or not |
---|
1903 | the condition is permanent, the status code 404 (Not Found) &SHOULD; be |
---|
1904 | used instead. |
---|
1905 | </t> |
---|
1906 | <t> |
---|
1907 | The 410 response is primarily intended to assist the task of web |
---|
1908 | maintenance by notifying the recipient that the resource is |
---|
1909 | intentionally unavailable and that the server owners desire that |
---|
1910 | remote links to that resource be removed. Such an event is common for |
---|
1911 | limited-time, promotional services and for resources belonging to |
---|
1912 | individuals no longer working at the server's site. It is not |
---|
1913 | necessary to mark all permanently unavailable resources as "gone" or |
---|
1914 | to keep the mark for any length of time — that is left to the |
---|
1915 | discretion of the server owner. |
---|
1916 | </t> |
---|
1917 | <t> |
---|
1918 | Caches &MAY; use a heuristic (see &p6-heuristic;) to determine freshness |
---|
1919 | for 410 responses. |
---|
1920 | </t> |
---|
1921 | </section> |
---|
1922 | |
---|
1923 | <section title="411 Length Required" anchor="status.411"> |
---|
1924 | <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/> |
---|
1925 | <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/> |
---|
1926 | <t> |
---|
1927 | The server refuses to accept the request without a defined Content-Length. |
---|
1928 | The client &MAY; repeat the request if it adds a valid |
---|
1929 | Content-Length header field containing the length of the message body |
---|
1930 | in the request message. |
---|
1931 | </t> |
---|
1932 | </section> |
---|
1933 | |
---|
1934 | <section title="413 Request Representation Too Large" anchor="status.413"> |
---|
1935 | <iref primary="true" item="413 Request Representation Too Large (status code)" x:for-anchor=""/> |
---|
1936 | <iref primary="true" item="Status Codes" subitem="413 Request Representation Too Large" x:for-anchor=""/> |
---|
1937 | <t> |
---|
1938 | The server is refusing to process a request because the request |
---|
1939 | representation is larger than the server is willing or able to process. The |
---|
1940 | server &MAY; close the connection to prevent the client from continuing |
---|
1941 | the request. |
---|
1942 | </t> |
---|
1943 | <t> |
---|
1944 | If the condition is temporary, the server &SHOULD; include a Retry-After |
---|
1945 | header field to indicate that it is temporary and after what |
---|
1946 | time the client &MAY; try again. |
---|
1947 | </t> |
---|
1948 | </section> |
---|
1949 | |
---|
1950 | <section title="414 URI Too Long" anchor="status.414"> |
---|
1951 | <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/> |
---|
1952 | <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> |
---|
1953 | <t> |
---|
1954 | The server is refusing to service the request because the effective request URI |
---|
1955 | is longer than the server is willing to interpret. This rare |
---|
1956 | condition is only likely to occur when a client has improperly |
---|
1957 | converted a POST request to a GET request with long query |
---|
1958 | information, when the client has descended into a URI "black hole" of |
---|
1959 | redirection (e.g., a redirected URI prefix that points to a suffix of |
---|
1960 | itself), or when the server is under attack by a client attempting to |
---|
1961 | exploit security holes present in some servers using fixed-length |
---|
1962 | buffers for reading or manipulating the request-target. |
---|
1963 | </t> |
---|
1964 | </section> |
---|
1965 | |
---|
1966 | <section title="415 Unsupported Media Type" anchor="status.415"> |
---|
1967 | <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/> |
---|
1968 | <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/> |
---|
1969 | <t> |
---|
1970 | The server is refusing to service the request because the request |
---|
1971 | payload is in a format not supported by this request method on the |
---|
1972 | target resource. |
---|
1973 | </t> |
---|
1974 | </section> |
---|
1975 | |
---|
1976 | <section title="417 Expectation Failed" anchor="status.417"> |
---|
1977 | <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/> |
---|
1978 | <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/> |
---|
1979 | <t> |
---|
1980 | The expectation given in an Expect header field (see <xref target="header.expect"/>) |
---|
1981 | could not be met by this server, or, if the server is a proxy, |
---|
1982 | the server has unambiguous evidence that the request could not be met |
---|
1983 | by the next-hop server. |
---|
1984 | </t> |
---|
1985 | </section> |
---|
1986 | |
---|
1987 | <section title="426 Upgrade Required" anchor="status.426"> |
---|
1988 | <iref primary="true" item="426 Upgrade Required (status code)" x:for-anchor=""/> |
---|
1989 | <iref primary="true" item="Status Codes" subitem="426 Upgrade Required" x:for-anchor=""/> |
---|
1990 | <t> |
---|
1991 | The request can not be completed without a prior protocol upgrade. This |
---|
1992 | response &MUST; include an Upgrade header field (&header-upgrade;) |
---|
1993 | specifying the required protocols. |
---|
1994 | </t> |
---|
1995 | <figure> |
---|
1996 | <preamble>Example:</preamble> |
---|
1997 | <artwork type="message/http; msgtype="response"" x:indent-with=" "> |
---|
1998 | HTTP/1.1 426 Upgrade Required |
---|
1999 | Upgrade: HTTP/3.0 |
---|
2000 | Connection: Upgrade |
---|
2001 | Content-Length: <x:length-of target="s426body"/> |
---|
2002 | Content-Type: text/plain |
---|
2003 | |
---|
2004 | <x:span anchor="s426body">This service requires use of the HTTP/3.0 protocol. |
---|
2005 | </x:span></artwork></figure> |
---|
2006 | <t> |
---|
2007 | The server &SHOULD; include a message body in the 426 response which |
---|
2008 | indicates in human readable form the reason for the error and describes any |
---|
2009 | alternative courses which may be available to the user. |
---|
2010 | </t> |
---|
2011 | </section> |
---|
2012 | </section> |
---|
2013 | |
---|
2014 | <section title="Server Error 5xx" anchor="status.5xx"> |
---|
2015 | <t> |
---|
2016 | Response status codes beginning with the digit "5" indicate cases in |
---|
2017 | which the server is aware that it has erred or is incapable of |
---|
2018 | performing the request. Except when responding to a HEAD request, the |
---|
2019 | server &SHOULD; include a representation containing an explanation of the |
---|
2020 | error situation, and whether it is a temporary or permanent |
---|
2021 | condition. User agents &SHOULD; display any included representation to the |
---|
2022 | user. These response codes are applicable to any request method. |
---|
2023 | </t> |
---|
2024 | |
---|
2025 | <section title="500 Internal Server Error" anchor="status.500"> |
---|
2026 | <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/> |
---|
2027 | <iref primary="true" item="Status Codes" subitem="500 Internal Server Error" x:for-anchor=""/> |
---|
2028 | <t> |
---|
2029 | The server encountered an unexpected condition which prevented it |
---|
2030 | from fulfilling the request. |
---|
2031 | </t> |
---|
2032 | </section> |
---|
2033 | |
---|
2034 | <section title="501 Not Implemented" anchor="status.501"> |
---|
2035 | <iref primary="true" item="501 Not Implemented (status code)" x:for-anchor=""/> |
---|
2036 | <iref primary="true" item="Status Codes" subitem="501 Not Implemented" x:for-anchor=""/> |
---|
2037 | <t> |
---|
2038 | The server does not support the functionality required to fulfill the |
---|
2039 | request. This is the appropriate response when the server does not |
---|
2040 | recognize the request method and is not capable of supporting it for |
---|
2041 | any resource. |
---|
2042 | </t> |
---|
2043 | </section> |
---|
2044 | |
---|
2045 | <section title="502 Bad Gateway" anchor="status.502"> |
---|
2046 | <iref primary="true" item="502 Bad Gateway (status code)" x:for-anchor=""/> |
---|
2047 | <iref primary="true" item="Status Codes" subitem="502 Bad Gateway" x:for-anchor=""/> |
---|
2048 | <t> |
---|
2049 | The server, while acting as a gateway or proxy, received an invalid |
---|
2050 | response from the upstream server it accessed in attempting to |
---|
2051 | fulfill the request. |
---|
2052 | </t> |
---|
2053 | </section> |
---|
2054 | |
---|
2055 | <section title="503 Service Unavailable" anchor="status.503"> |
---|
2056 | <iref primary="true" item="503 Service Unavailable (status code)" x:for-anchor=""/> |
---|
2057 | <iref primary="true" item="Status Codes" subitem="503 Service Unavailable" x:for-anchor=""/> |
---|
2058 | <t> |
---|
2059 | The server is currently unable to handle the request due to a |
---|
2060 | temporary overloading or maintenance of the server. |
---|
2061 | </t> |
---|
2062 | <t> |
---|
2063 | The implication is that this is a temporary condition which will be |
---|
2064 | alleviated after some delay. If known, the length of the delay &MAY; be |
---|
2065 | indicated in a Retry-After header field (<xref target="header.retry-after"/>). |
---|
2066 | If no Retry-After is given, the client &SHOULD; handle the response as it |
---|
2067 | would for a 500 response. |
---|
2068 | </t> |
---|
2069 | <x:note> |
---|
2070 | <t> |
---|
2071 | <x:h>Note:</x:h> The existence of the 503 status code does not imply that a |
---|
2072 | server has to use it when becoming overloaded. Some servers might wish |
---|
2073 | to simply refuse the connection. |
---|
2074 | </t> |
---|
2075 | </x:note> |
---|
2076 | </section> |
---|
2077 | |
---|
2078 | <section title="504 Gateway Timeout" anchor="status.504"> |
---|
2079 | <iref primary="true" item="504 Gateway Timeout (status code)" x:for-anchor=""/> |
---|
2080 | <iref primary="true" item="Status Codes" subitem="504 Gateway Timeout" x:for-anchor=""/> |
---|
2081 | <t> |
---|
2082 | The server, while acting as a gateway or proxy, did not receive a |
---|
2083 | timely response from the upstream server specified by the URI (e.g., |
---|
2084 | HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed |
---|
2085 | to access in attempting to complete the request. |
---|
2086 | </t> |
---|
2087 | <x:note> |
---|
2088 | <t> |
---|
2089 | <x:h>Note</x:h> to implementors: some deployed proxies are known to |
---|
2090 | return 400 or 500 when DNS lookups time out. |
---|
2091 | </t> |
---|
2092 | </x:note> |
---|
2093 | </section> |
---|
2094 | |
---|
2095 | <section title="505 HTTP Version Not Supported" anchor="status.505"> |
---|
2096 | <iref primary="true" item="505 HTTP Version Not Supported (status code)" x:for-anchor=""/> |
---|
2097 | <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/> |
---|
2098 | <t> |
---|
2099 | The server does not support, or refuses to support, the protocol |
---|
2100 | version that was used in the request message. The server is |
---|
2101 | indicating that it is unable or unwilling to complete the request |
---|
2102 | using the same major version as the client, as described in &http-version;, |
---|
2103 | other than with this error message. The response &SHOULD; contain |
---|
2104 | a representation describing why that version is not supported and what other |
---|
2105 | protocols are supported by that server. |
---|
2106 | </t> |
---|
2107 | |
---|
2108 | </section> |
---|
2109 | </section> |
---|
2110 | |
---|
2111 | </section> |
---|
2112 | |
---|
2113 | <section title="Representation" anchor="representation"> |
---|
2114 | <t> |
---|
2115 | Request and Response messages &MAY; transfer a representation if not otherwise |
---|
2116 | restricted by the request method or response status code. A representation |
---|
2117 | consists of metadata (representation header fields) and data (representation |
---|
2118 | body). When a complete or partial representation is enclosed in an HTTP message, |
---|
2119 | it is referred to as the payload of the message. HTTP representations |
---|
2120 | are defined in &payload;. |
---|
2121 | </t> |
---|
2122 | <t> |
---|
2123 | A representation body is only present in a message when a message body is |
---|
2124 | present, as described in &message-body;. The representation body is obtained |
---|
2125 | from the message body by decoding any Transfer-Encoding that might |
---|
2126 | have been applied to ensure safe and proper transfer of the message. |
---|
2127 | </t> |
---|
2128 | |
---|
2129 | <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation"> |
---|
2130 | <t> |
---|
2131 | It is sometimes necessary to determine an identifier for the resource |
---|
2132 | associated with a representation. |
---|
2133 | </t> |
---|
2134 | <t> |
---|
2135 | An HTTP request representation, when present, is always associated with an |
---|
2136 | anonymous (i.e., unidentified) resource. |
---|
2137 | </t> |
---|
2138 | <t> |
---|
2139 | In the common case, an HTTP response is a representation of the target |
---|
2140 | resource (see &effective-request-uri;). However, this is not always the |
---|
2141 | case. To determine the URI of the resource a response is associated with, |
---|
2142 | the following rules are used (with the first applicable one being selected): |
---|
2143 | </t> |
---|
2144 | <t><list style="numbers"> |
---|
2145 | <t>If the response status code is 200 or 203 and the request method was GET, |
---|
2146 | the response payload is a representation of the target resource.</t> |
---|
2147 | <t>If the response status code is 204, 206, or 304 and the request method was GET |
---|
2148 | or HEAD, the response payload is a partial representation of the target |
---|
2149 | resource.</t> |
---|
2150 | <t>If the response has a Content-Location header field, and that URI is the same |
---|
2151 | as the effective request URI, the response payload is a representation of the |
---|
2152 | target resource.</t> |
---|
2153 | <t>If the response has a Content-Location header field, and that URI is not the |
---|
2154 | same as the effective request URI, then the response asserts that its |
---|
2155 | payload is a representation of the resource identified by the |
---|
2156 | Content-Location URI. However, such an assertion cannot be trusted unless |
---|
2157 | it can be verified by other means (not defined by HTTP).</t> |
---|
2158 | <t>Otherwise, the response is a representation of an anonymous (i.e., |
---|
2159 | unidentified) resource.</t> |
---|
2160 | </list></t> |
---|
2161 | <t> |
---|
2162 | <cref anchor="TODO-req-uri"> |
---|
2163 | The comparison function is going to have to be defined somewhere, |
---|
2164 | because we already need to compare URIs for things like cache invalidation.</cref> |
---|
2165 | </t> |
---|
2166 | </section> |
---|
2167 | |
---|
2168 | </section> |
---|
2169 | |
---|
2170 | |
---|
2171 | <section title="Common Protocol Parameters" anchor="common.protocol.parameters"> |
---|
2172 | <section title="Date/Time Formats" anchor="http.date"> |
---|
2173 | <x:anchor-alias value="HTTP-date"/> |
---|
2174 | <t> |
---|
2175 | HTTP applications have historically allowed three different formats |
---|
2176 | for date/time stamps. However, the preferred format is a fixed-length subset |
---|
2177 | of that defined by <xref target="RFC1123"/>: |
---|
2178 | </t> |
---|
2179 | <figure><artwork type="example" x:indent-with=" "> |
---|
2180 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |
---|
2181 | </artwork></figure> |
---|
2182 | <t> |
---|
2183 | The other formats are described here only for compatibility with obsolete |
---|
2184 | implementations. |
---|
2185 | </t> |
---|
2186 | <figure><artwork type="example" x:indent-with=" "> |
---|
2187 | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
---|
2188 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
---|
2189 | </artwork></figure> |
---|
2190 | <t> |
---|
2191 | HTTP/1.1 clients and servers that parse a date value &MUST; accept |
---|
2192 | all three formats (for compatibility with HTTP/1.0), though they &MUST; |
---|
2193 | only generate the RFC 1123 format for representing HTTP-date values |
---|
2194 | in header fields. |
---|
2195 | </t> |
---|
2196 | <t> |
---|
2197 | All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time |
---|
2198 | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
---|
2199 | equal to UTC (Coordinated Universal Time). This is indicated in the |
---|
2200 | first two formats by the inclusion of "GMT" as the three-letter |
---|
2201 | abbreviation for time zone, and &MUST; be assumed when reading the |
---|
2202 | asctime format. HTTP-date is case sensitive and &MUST-NOT; include |
---|
2203 | additional whitespace beyond that specifically included as SP in the |
---|
2204 | grammar. |
---|
2205 | </t> |
---|
2206 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/> |
---|
2207 | <x:ref>HTTP-date</x:ref> = <x:ref>rfc1123-date</x:ref> / <x:ref>obs-date</x:ref> |
---|
2208 | </artwork></figure> |
---|
2209 | <t anchor="preferred.date.format"> |
---|
2210 | <x:anchor-alias value="rfc1123-date"/> |
---|
2211 | <x:anchor-alias value="time-of-day"/> |
---|
2212 | <x:anchor-alias value="hour"/> |
---|
2213 | <x:anchor-alias value="minute"/> |
---|
2214 | <x:anchor-alias value="second"/> |
---|
2215 | <x:anchor-alias value="day-name"/> |
---|
2216 | <x:anchor-alias value="day"/> |
---|
2217 | <x:anchor-alias value="month"/> |
---|
2218 | <x:anchor-alias value="year"/> |
---|
2219 | <x:anchor-alias value="GMT"/> |
---|
2220 | Preferred format: |
---|
2221 | </t> |
---|
2222 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/> |
---|
2223 | <x:ref>rfc1123-date</x:ref> = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref> |
---|
2224 | ; fixed length subset of the format defined in |
---|
2225 | ; <xref target="RFC1123" x:fmt="of" x:sec="5.2.14"/> |
---|
2226 | |
---|
2227 | <x:ref>day-name</x:ref> = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive |
---|
2228 | / <x:abnf-char-sequence>"Tue"</x:abnf-char-sequence> ; "Tue", case-sensitive |
---|
2229 | / <x:abnf-char-sequence>"Wed"</x:abnf-char-sequence> ; "Wed", case-sensitive |
---|
2230 | / <x:abnf-char-sequence>"Thu"</x:abnf-char-sequence> ; "Thu", case-sensitive |
---|
2231 | / <x:abnf-char-sequence>"Fri"</x:abnf-char-sequence> ; "Fri", case-sensitive |
---|
2232 | / <x:abnf-char-sequence>"Sat"</x:abnf-char-sequence> ; "Sat", case-sensitive |
---|
2233 | / <x:abnf-char-sequence>"Sun"</x:abnf-char-sequence> ; "Sun", case-sensitive |
---|
2234 | |
---|
2235 | <x:ref>date1</x:ref> = <x:ref>day</x:ref> <x:ref>SP</x:ref> <x:ref>month</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref> |
---|
2236 | ; e.g., 02 Jun 1982 |
---|
2237 | |
---|
2238 | <x:ref>day</x:ref> = 2<x:ref>DIGIT</x:ref> |
---|
2239 | <x:ref>month</x:ref> = <x:abnf-char-sequence>"Jan"</x:abnf-char-sequence> ; "Jan", case-sensitive |
---|
2240 | / <x:abnf-char-sequence>"Feb"</x:abnf-char-sequence> ; "Feb", case-sensitive |
---|
2241 | / <x:abnf-char-sequence>"Mar"</x:abnf-char-sequence> ; "Mar", case-sensitive |
---|
2242 | / <x:abnf-char-sequence>"Apr"</x:abnf-char-sequence> ; "Apr", case-sensitive |
---|
2243 | / <x:abnf-char-sequence>"May"</x:abnf-char-sequence> ; "May", case-sensitive |
---|
2244 | / <x:abnf-char-sequence>"Jun"</x:abnf-char-sequence> ; "Jun", case-sensitive |
---|
2245 | / <x:abnf-char-sequence>"Jul"</x:abnf-char-sequence> ; "Jul", case-sensitive |
---|
2246 | / <x:abnf-char-sequence>"Aug"</x:abnf-char-sequence> ; "Aug", case-sensitive |
---|
2247 | / <x:abnf-char-sequence>"Sep"</x:abnf-char-sequence> ; "Sep", case-sensitive |
---|
2248 | / <x:abnf-char-sequence>"Oct"</x:abnf-char-sequence> ; "Oct", case-sensitive |
---|
2249 | / <x:abnf-char-sequence>"Nov"</x:abnf-char-sequence> ; "Nov", case-sensitive |
---|
2250 | / <x:abnf-char-sequence>"Dec"</x:abnf-char-sequence> ; "Dec", case-sensitive |
---|
2251 | <x:ref>year</x:ref> = 4<x:ref>DIGIT</x:ref> |
---|
2252 | |
---|
2253 | <x:ref>GMT</x:ref> = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive |
---|
2254 | |
---|
2255 | <x:ref>time-of-day</x:ref> = <x:ref>hour</x:ref> ":" <x:ref>minute</x:ref> ":" <x:ref>second</x:ref> |
---|
2256 | ; 00:00:00 - 23:59:59 |
---|
2257 | |
---|
2258 | <x:ref>hour</x:ref> = 2<x:ref>DIGIT</x:ref> |
---|
2259 | <x:ref>minute</x:ref> = 2<x:ref>DIGIT</x:ref> |
---|
2260 | <x:ref>second</x:ref> = 2<x:ref>DIGIT</x:ref> |
---|
2261 | </artwork></figure> |
---|
2262 | <t> |
---|
2263 | The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>, |
---|
2264 | <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref> are the |
---|
2265 | same as those defined for the RFC 5322 constructs |
---|
2266 | with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>). |
---|
2267 | </t> |
---|
2268 | <t anchor="obsolete.date.formats"> |
---|
2269 | <x:anchor-alias value="obs-date"/> |
---|
2270 | <x:anchor-alias value="rfc850-date"/> |
---|
2271 | <x:anchor-alias value="asctime-date"/> |
---|
2272 | <x:anchor-alias value="date1"/> |
---|
2273 | <x:anchor-alias value="date2"/> |
---|
2274 | <x:anchor-alias value="date3"/> |
---|
2275 | <x:anchor-alias value="rfc1123-date"/> |
---|
2276 | <x:anchor-alias value="day-name-l"/> |
---|
2277 | Obsolete formats: |
---|
2278 | </t> |
---|
2279 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="obs-date"/> |
---|
2280 | <x:ref>obs-date</x:ref> = <x:ref>rfc850-date</x:ref> / <x:ref>asctime-date</x:ref> |
---|
2281 | </artwork></figure> |
---|
2282 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc850-date"/> |
---|
2283 | <x:ref>rfc850-date</x:ref> = <x:ref>day-name-l</x:ref> "," <x:ref>SP</x:ref> <x:ref>date2</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref> |
---|
2284 | <x:ref>date2</x:ref> = <x:ref>day</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref> |
---|
2285 | ; day-month-year (e.g., 02-Jun-82) |
---|
2286 | |
---|
2287 | <x:ref>day-name-l</x:ref> = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive |
---|
2288 | / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive |
---|
2289 | / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive |
---|
2290 | / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive |
---|
2291 | / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive |
---|
2292 | / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive |
---|
2293 | / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive |
---|
2294 | </artwork></figure> |
---|
2295 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/> |
---|
2296 | <x:ref>asctime-date</x:ref> = <x:ref>day-name</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref> |
---|
2297 | <x:ref>date3</x:ref> = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> / ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> )) |
---|
2298 | ; month day (e.g., Jun 2) |
---|
2299 | </artwork></figure> |
---|
2300 | <x:note> |
---|
2301 | <t> |
---|
2302 | <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in |
---|
2303 | accepting date values that might have been sent by non-HTTP |
---|
2304 | applications, as is sometimes the case when retrieving or posting |
---|
2305 | messages via proxies/gateways to SMTP or NNTP. |
---|
2306 | </t> |
---|
2307 | </x:note> |
---|
2308 | <x:note> |
---|
2309 | <t> |
---|
2310 | <x:h>Note:</x:h> HTTP requirements for the date/time stamp format apply only |
---|
2311 | to their usage within the protocol stream. Clients and servers are |
---|
2312 | not required to use these formats for user presentation, request |
---|
2313 | logging, etc. |
---|
2314 | </t> |
---|
2315 | </x:note> |
---|
2316 | </section> |
---|
2317 | |
---|
2318 | <section title="Product Tokens" anchor="product.tokens"> |
---|
2319 | <x:anchor-alias value="product"/> |
---|
2320 | <x:anchor-alias value="product-version"/> |
---|
2321 | <t> |
---|
2322 | Product tokens are used to allow communicating applications to |
---|
2323 | identify themselves by software name and version. Most fields using |
---|
2324 | product tokens also allow sub-products which form a significant part |
---|
2325 | of the application to be listed, separated by whitespace. By |
---|
2326 | convention, the products are listed in order of their significance |
---|
2327 | for identifying the application. |
---|
2328 | </t> |
---|
2329 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/> |
---|
2330 | <x:ref>product</x:ref> = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>] |
---|
2331 | <x:ref>product-version</x:ref> = <x:ref>token</x:ref> |
---|
2332 | </artwork></figure> |
---|
2333 | <t> |
---|
2334 | Examples: |
---|
2335 | </t> |
---|
2336 | <figure><artwork type="example"> |
---|
2337 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
2338 | Server: Apache/0.8.4 |
---|
2339 | </artwork></figure> |
---|
2340 | <t> |
---|
2341 | Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be |
---|
2342 | used for advertising or other non-essential information. Although any |
---|
2343 | token octet &MAY; appear in a product-version, this token &SHOULD; |
---|
2344 | only be used for a version identifier (i.e., successive versions of |
---|
2345 | the same product &SHOULD; only differ in the product-version portion of |
---|
2346 | the product value). |
---|
2347 | </t> |
---|
2348 | </section> |
---|
2349 | </section> |
---|
2350 | |
---|
2351 | <section title="Header Field Definitions" anchor="header.field.definitions"> |
---|
2352 | <t> |
---|
2353 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
2354 | related to request and response semantics. |
---|
2355 | </t> |
---|
2356 | |
---|
2357 | <section title="Allow" anchor="header.allow"> |
---|
2358 | <iref primary="true" item="Allow header field" x:for-anchor=""/> |
---|
2359 | <iref primary="true" item="Header Fields" subitem="Allow" x:for-anchor=""/> |
---|
2360 | <x:anchor-alias value="Allow"/> |
---|
2361 | <t> |
---|
2362 | The "Allow" header field lists the set of methods advertised as |
---|
2363 | supported by the target resource. The purpose of this field is strictly to |
---|
2364 | inform the recipient of valid request methods associated with the resource. |
---|
2365 | </t> |
---|
2366 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/> |
---|
2367 | <x:ref>Allow</x:ref> = #<x:ref>method</x:ref> |
---|
2368 | </artwork></figure> |
---|
2369 | <t> |
---|
2370 | Example of use: |
---|
2371 | </t> |
---|
2372 | <figure><artwork type="example"> |
---|
2373 | Allow: GET, HEAD, PUT |
---|
2374 | </artwork></figure> |
---|
2375 | <t> |
---|
2376 | The actual set of allowed methods is defined by the origin server at the |
---|
2377 | time of each request. |
---|
2378 | </t> |
---|
2379 | <t> |
---|
2380 | A proxy &MUST-NOT; modify the Allow header field — it does not need to |
---|
2381 | understand all the methods specified in order to handle them according to |
---|
2382 | the generic message handling rules. |
---|
2383 | </t> |
---|
2384 | </section> |
---|
2385 | |
---|
2386 | <section title="Date" anchor="header.date"> |
---|
2387 | <iref primary="true" item="Date header field" x:for-anchor=""/> |
---|
2388 | <iref primary="true" item="Header Fields" subitem="Date" x:for-anchor=""/> |
---|
2389 | <x:anchor-alias value="Date"/> |
---|
2390 | <t> |
---|
2391 | The "Date" header field represents the date and time at which |
---|
2392 | the message was originated, having the same semantics as the Origination |
---|
2393 | Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. |
---|
2394 | The field value is an HTTP-date, as defined in <xref target="http.date"/>; |
---|
2395 | it &MUST; be sent in rfc1123-date format. |
---|
2396 | </t> |
---|
2397 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/> |
---|
2398 | <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref> |
---|
2399 | </artwork></figure> |
---|
2400 | <t> |
---|
2401 | An example is |
---|
2402 | </t> |
---|
2403 | <figure><artwork type="example"> |
---|
2404 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
---|
2405 | </artwork></figure> |
---|
2406 | <t> |
---|
2407 | Origin servers &MUST; include a Date header field in all responses, |
---|
2408 | except in these cases: |
---|
2409 | <list style="numbers"> |
---|
2410 | <t>If the response status code is 100 (Continue) or 101 (Switching |
---|
2411 | Protocols), the response &MAY; include a Date header field, at |
---|
2412 | the server's option.</t> |
---|
2413 | |
---|
2414 | <t>If the response status code conveys a server error, e.g., 500 |
---|
2415 | (Internal Server Error) or 503 (Service Unavailable), and it is |
---|
2416 | inconvenient or impossible to generate a valid Date.</t> |
---|
2417 | |
---|
2418 | <t>If the server does not have a clock that can provide a |
---|
2419 | reasonable approximation of the current time, its responses |
---|
2420 | &MUST-NOT; include a Date header field.</t> |
---|
2421 | </list> |
---|
2422 | </t> |
---|
2423 | <t> |
---|
2424 | A received message that does not have a Date header field &MUST; be |
---|
2425 | assigned one by the recipient if the message will be cached by that |
---|
2426 | recipient. |
---|
2427 | </t> |
---|
2428 | <t> |
---|
2429 | Clients can use the Date header field as well; in order to keep request |
---|
2430 | messages small, they are advised not to include it when it doesn't convey |
---|
2431 | any useful information (as is usually the case for requests that do not |
---|
2432 | contain a payload). |
---|
2433 | </t> |
---|
2434 | <t> |
---|
2435 | The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and |
---|
2436 | time subsequent to the generation of the message. It &SHOULD; represent |
---|
2437 | the best available approximation of the date and time of message |
---|
2438 | generation, unless the implementation has no means of generating a |
---|
2439 | reasonably accurate date and time. In theory, the date ought to |
---|
2440 | represent the moment just before the payload is generated. In |
---|
2441 | practice, the date can be generated at any time during the message |
---|
2442 | origination without affecting its semantic value. |
---|
2443 | </t> |
---|
2444 | </section> |
---|
2445 | |
---|
2446 | <section title="Expect" anchor="header.expect"> |
---|
2447 | <iref primary="true" item="Expect header field" x:for-anchor=""/> |
---|
2448 | <iref primary="true" item="Header Fields" subitem="Expect" x:for-anchor=""/> |
---|
2449 | <x:anchor-alias value="Expect"/> |
---|
2450 | <x:anchor-alias value="expectation"/> |
---|
2451 | <x:anchor-alias value="expect-param"/> |
---|
2452 | <x:anchor-alias value="expect-name"/> |
---|
2453 | <x:anchor-alias value="expect-value"/> |
---|
2454 | <t> |
---|
2455 | The "Expect" header field is used to indicate that particular |
---|
2456 | server behaviors are required by the client. |
---|
2457 | </t> |
---|
2458 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expect-param"/><iref primary="true" item="Grammar" subitem="expect-value"/><iref primary="true" item="Grammar" subitem="expect-name"/> |
---|
2459 | <x:ref>Expect</x:ref> = 1#<x:ref>expectation</x:ref> |
---|
2460 | |
---|
2461 | <x:ref>expectation</x:ref> = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ] |
---|
2462 | *( <x:ref>OWS</x:ref> ";" [ <x:ref>OWS</x:ref> <x:ref>expect-param</x:ref> ] ) |
---|
2463 | <x:ref>expect-param</x:ref> = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ] |
---|
2464 | |
---|
2465 | <x:ref>expect-name</x:ref> = <x:ref>token</x:ref> |
---|
2466 | <x:ref>expect-value</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> |
---|
2467 | </artwork></figure> |
---|
2468 | <t> |
---|
2469 | If all received Expect header field(s) are syntactically valid but contain |
---|
2470 | an expectation that the recipient does not understand or cannot comply with, |
---|
2471 | the recipient &MUST; respond with a 417 (Expectation Failed) status code. A |
---|
2472 | recipient of a syntactically invalid Expectation header field &MUST; respond |
---|
2473 | with a 4xx status code other than 417. |
---|
2474 | </t> |
---|
2475 | <t> |
---|
2476 | The only expectation defined by this specification is: |
---|
2477 | </t> |
---|
2478 | <t><iref primary="true" item="100-continue (expect value)"/><iref primary="true" item="Expect Values" subitem="100-continue"/> |
---|
2479 | 100-continue |
---|
2480 | <list> |
---|
2481 | <t> |
---|
2482 | The "100-continue" expectation is defined &use100;. It does not support |
---|
2483 | any expect-params. |
---|
2484 | </t> |
---|
2485 | </list> |
---|
2486 | </t> |
---|
2487 | <t> |
---|
2488 | Comparison is case-insensitive for names (expect-name), and case-sensitive |
---|
2489 | for values (expect-value). |
---|
2490 | </t> |
---|
2491 | <t> |
---|
2492 | The Expect mechanism is hop-by-hop: the above requirements apply to any |
---|
2493 | server, including proxies. However, the Expect header field itself is |
---|
2494 | end-to-end; it &MUST; be forwarded if the request is forwarded. |
---|
2495 | </t> |
---|
2496 | <t> |
---|
2497 | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect |
---|
2498 | header field. |
---|
2499 | </t> |
---|
2500 | </section> |
---|
2501 | |
---|
2502 | <section title="From" anchor="header.from"> |
---|
2503 | <iref primary="true" item="From header field" x:for-anchor=""/> |
---|
2504 | <iref primary="true" item="Header Fields" subitem="From" x:for-anchor=""/> |
---|
2505 | <x:anchor-alias value="From"/> |
---|
2506 | <x:anchor-alias value="mailbox"/> |
---|
2507 | <t> |
---|
2508 | The "From" header field, if given, &SHOULD; contain an Internet |
---|
2509 | e-mail address for the human user who controls the requesting user |
---|
2510 | agent. The address &SHOULD; be machine-usable, as defined by "mailbox" |
---|
2511 | in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>: |
---|
2512 | </t> |
---|
2513 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/> |
---|
2514 | <x:ref>From</x:ref> = <x:ref>mailbox</x:ref> |
---|
2515 | |
---|
2516 | <x:ref>mailbox</x:ref> = <mailbox, defined in <xref x:sec="3.4" x:fmt="," target="RFC5322"/>> |
---|
2517 | </artwork></figure> |
---|
2518 | <t> |
---|
2519 | An example is: |
---|
2520 | </t> |
---|
2521 | <figure><artwork type="example"> |
---|
2522 | From: webmaster@example.org |
---|
2523 | </artwork></figure> |
---|
2524 | <t> |
---|
2525 | This header field &MAY; be used for logging purposes and as a means for |
---|
2526 | identifying the source of invalid or unwanted requests. It &SHOULD-NOT; |
---|
2527 | be used as an insecure form of access protection. The interpretation |
---|
2528 | of this field is that the request is being performed on behalf of the |
---|
2529 | person given, who accepts responsibility for the method performed. In |
---|
2530 | particular, robot agents &SHOULD; include this header field so that the |
---|
2531 | person responsible for running the robot can be contacted if problems |
---|
2532 | occur on the receiving end. |
---|
2533 | </t> |
---|
2534 | <t> |
---|
2535 | The Internet e-mail address in this field &MAY; be separate from the |
---|
2536 | Internet host which issued the request. For example, when a request |
---|
2537 | is passed through a proxy the original issuer's address &SHOULD; be |
---|
2538 | used. |
---|
2539 | </t> |
---|
2540 | <t> |
---|
2541 | The client &SHOULD-NOT; send the From header field without the user's |
---|
2542 | approval, as it might conflict with the user's privacy interests or |
---|
2543 | their site's security policy. It is strongly recommended that the |
---|
2544 | user be able to disable, enable, and modify the value of this field |
---|
2545 | at any time prior to a request. |
---|
2546 | </t> |
---|
2547 | </section> |
---|
2548 | |
---|
2549 | <section title="Location" anchor="header.location"> |
---|
2550 | <iref primary="true" item="Location header field" x:for-anchor=""/> |
---|
2551 | <iref primary="true" item="Header Fields" subitem="Location" x:for-anchor=""/> |
---|
2552 | <x:anchor-alias value="Location"/> |
---|
2553 | <t> |
---|
2554 | The "Location" header field &MAY; be sent in responses to refer to |
---|
2555 | a specific resource in accordance with the semantics of the status |
---|
2556 | code. |
---|
2557 | </t> |
---|
2558 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/> |
---|
2559 | <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref> |
---|
2560 | </artwork></figure> |
---|
2561 | <t> |
---|
2562 | For 201 (Created) responses, the Location is the URI of the new resource |
---|
2563 | which was created by the request. For 3xx responses, the location &SHOULD; |
---|
2564 | indicate the server's preferred URI for automatic redirection to the |
---|
2565 | resource. |
---|
2566 | </t> |
---|
2567 | <t> |
---|
2568 | The field value consists of a single URI-reference. When it has the form |
---|
2569 | of a relative reference (<xref target="RFC3986" x:fmt="," x:sec="4.2"/>), |
---|
2570 | the final value is computed by resolving it against the effective request |
---|
2571 | URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>). If the original URI, as |
---|
2572 | navigated to by the user agent, did contain a fragment identifier, and the |
---|
2573 | final value does not, then the original URI's fragment identifier is added |
---|
2574 | to the final value. |
---|
2575 | </t> |
---|
2576 | <figure> |
---|
2577 | <preamble>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc--> |
---|
2578 | <artwork type="example"> |
---|
2579 | Location: /pub/WWW/People.html#tim |
---|
2580 | </artwork> |
---|
2581 | <postamble>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</postamble> |
---|
2582 | </figure> |
---|
2583 | <figure> |
---|
2584 | <preamble>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc--> |
---|
2585 | <artwork type="example"> |
---|
2586 | Location: http://www.example.net/index.html |
---|
2587 | </artwork> |
---|
2588 | <postamble>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</postamble> |
---|
2589 | </figure> |
---|
2590 | <x:note> |
---|
2591 | <t> |
---|
2592 | <x:h>Note:</x:h> Some recipients attempt to recover from Location fields |
---|
2593 | that are not valid URI references. This specification does not mandate or |
---|
2594 | define such processing, but does allow it (see <xref target="intro.conformance.and.error.handling"/>). |
---|
2595 | </t> |
---|
2596 | </x:note> |
---|
2597 | <t> |
---|
2598 | There are circumstances in which a fragment identifier in a Location URI |
---|
2599 | would not be appropriate. For instance, when it appears in a 201 Created |
---|
2600 | response, where the Location header field specifies the URI for the entire |
---|
2601 | created resource. |
---|
2602 | </t> |
---|
2603 | <x:note> |
---|
2604 | <t> |
---|
2605 | <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs |
---|
2606 | from Location in that the Content-Location identifies the most specific |
---|
2607 | resource corresponding to the enclosed representation. |
---|
2608 | It is therefore possible for a response to contain header fields for |
---|
2609 | both Location and Content-Location. |
---|
2610 | </t> |
---|
2611 | </x:note> |
---|
2612 | </section> |
---|
2613 | |
---|
2614 | <section title="Max-Forwards" anchor="header.max-forwards"> |
---|
2615 | <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/> |
---|
2616 | <iref primary="true" item="Header Fields" subitem="Max-Forwards" x:for-anchor=""/> |
---|
2617 | <x:anchor-alias value="Max-Forwards"/> |
---|
2618 | <t> |
---|
2619 | The "Max-Forwards" header field provides a mechanism with the |
---|
2620 | TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) |
---|
2621 | methods to limit the number of times that the request is forwarded by |
---|
2622 | proxies. This can be useful when the client is attempting to |
---|
2623 | trace a request which appears to be failing or looping mid-chain. |
---|
2624 | </t> |
---|
2625 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/> |
---|
2626 | <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
2627 | </artwork></figure> |
---|
2628 | <t> |
---|
2629 | The Max-Forwards value is a decimal integer indicating the remaining |
---|
2630 | number of times this request message can be forwarded. |
---|
2631 | </t> |
---|
2632 | <t> |
---|
2633 | Each recipient of a TRACE or OPTIONS request |
---|
2634 | containing a Max-Forwards header field &MUST; check and update its |
---|
2635 | value prior to forwarding the request. If the received value is zero |
---|
2636 | (0), the recipient &MUST-NOT; forward the request; instead, it &MUST; |
---|
2637 | respond as the final recipient. If the received Max-Forwards value is |
---|
2638 | greater than zero, then the forwarded message &MUST; contain an updated |
---|
2639 | Max-Forwards field with a value decremented by one (1). |
---|
2640 | </t> |
---|
2641 | <t> |
---|
2642 | The Max-Forwards header field &MAY; be ignored for all other request |
---|
2643 | methods. |
---|
2644 | </t> |
---|
2645 | </section> |
---|
2646 | |
---|
2647 | <section title="Referer" anchor="header.referer"> |
---|
2648 | <iref primary="true" item="Referer header field" x:for-anchor=""/> |
---|
2649 | <iref primary="true" item="Header Fields" subitem="Referer" x:for-anchor=""/> |
---|
2650 | <x:anchor-alias value="Referer"/> |
---|
2651 | <t> |
---|
2652 | The "Referer" [sic] header field allows the client to specify the |
---|
2653 | URI of the resource from which the target URI was obtained (the |
---|
2654 | "referrer", although the header field is misspelled.). |
---|
2655 | </t> |
---|
2656 | <t> |
---|
2657 | The Referer header field allows servers to generate lists of back-links to |
---|
2658 | resources for interest, logging, optimized caching, etc. It also allows |
---|
2659 | obsolete or mistyped links to be traced for maintenance. Some servers use |
---|
2660 | Referer as a means of controlling where they allow links from (so-called |
---|
2661 | "deep linking"), but legitimate requests do not always |
---|
2662 | contain a Referer header field. |
---|
2663 | </t> |
---|
2664 | <t> |
---|
2665 | If the target URI was obtained from a source that does not have its own |
---|
2666 | URI (e.g., input from the user keyboard), the Referer field &MUST; either be |
---|
2667 | sent with the value "about:blank", or not be sent at all. Note that this |
---|
2668 | requirement does not apply to sources with non-HTTP URIs (e.g., FTP). |
---|
2669 | </t> |
---|
2670 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/> |
---|
2671 | <x:ref>Referer</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> |
---|
2672 | </artwork></figure> |
---|
2673 | <t> |
---|
2674 | Example: |
---|
2675 | </t> |
---|
2676 | <figure><artwork type="example"> |
---|
2677 | Referer: http://www.example.org/hypertext/Overview.html |
---|
2678 | </artwork></figure> |
---|
2679 | <t> |
---|
2680 | If the field value is a relative URI, it &SHOULD; be interpreted |
---|
2681 | relative to the effective request URI. The URI &MUST-NOT; include a fragment. See |
---|
2682 | <xref target="encoding.sensitive.information.in.uris"/> for security considerations. |
---|
2683 | </t> |
---|
2684 | </section> |
---|
2685 | |
---|
2686 | <section title="Retry-After" anchor="header.retry-after"> |
---|
2687 | <iref primary="true" item="Retry-After header field" x:for-anchor=""/> |
---|
2688 | <iref primary="true" item="Header Fields" subitem="Retry-After" x:for-anchor=""/> |
---|
2689 | <x:anchor-alias value="Retry-After"/> |
---|
2690 | <t> |
---|
2691 | The header "Retry-After" field can be used with a 503 (Service |
---|
2692 | Unavailable) response to indicate how long the service is expected to |
---|
2693 | be unavailable to the requesting client. This field &MAY; also be used |
---|
2694 | with any 3xx (Redirection) response to indicate the minimum time the |
---|
2695 | user-agent is asked to wait before issuing the redirected request. |
---|
2696 | </t> |
---|
2697 | <t> |
---|
2698 | The value of this field can be either an HTTP-date or an integer number |
---|
2699 | of seconds (in decimal) after the time of the response. |
---|
2700 | </t> |
---|
2701 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Retry-After"/> |
---|
2702 | <x:ref>Retry-After</x:ref> = <x:ref>HTTP-date</x:ref> / <x:ref>delta-seconds</x:ref> |
---|
2703 | </artwork></figure> |
---|
2704 | <t anchor="rule.delta-seconds"> |
---|
2705 | <x:anchor-alias value="delta-seconds"/> |
---|
2706 | Time spans are non-negative decimal integers, representing time in |
---|
2707 | seconds. |
---|
2708 | </t> |
---|
2709 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/> |
---|
2710 | <x:ref>delta-seconds</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
2711 | </artwork></figure> |
---|
2712 | <t> |
---|
2713 | Two examples of its use are |
---|
2714 | </t> |
---|
2715 | <figure><artwork type="example"> |
---|
2716 | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
---|
2717 | Retry-After: 120 |
---|
2718 | </artwork></figure> |
---|
2719 | <t> |
---|
2720 | In the latter example, the delay is 2 minutes. |
---|
2721 | </t> |
---|
2722 | </section> |
---|
2723 | |
---|
2724 | <section title="Server" anchor="header.server"> |
---|
2725 | <iref primary="true" item="Server header field" x:for-anchor=""/> |
---|
2726 | <iref primary="true" item="Header Fields" subitem="Server" x:for-anchor=""/> |
---|
2727 | <x:anchor-alias value="Server"/> |
---|
2728 | <t> |
---|
2729 | The "Server" header field contains information about the |
---|
2730 | software used by the origin server to handle the request. |
---|
2731 | </t> |
---|
2732 | <t> |
---|
2733 | The field can contain multiple |
---|
2734 | product tokens (<xref target="product.tokens"/>) and |
---|
2735 | comments (&header-fields;) identifying the server and any significant |
---|
2736 | subproducts. The product tokens are listed in order of their significance |
---|
2737 | for identifying the application. |
---|
2738 | </t> |
---|
2739 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/> |
---|
2740 | <x:ref>Server</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) ) |
---|
2741 | </artwork></figure> |
---|
2742 | <t> |
---|
2743 | Example: |
---|
2744 | </t> |
---|
2745 | <figure><artwork type="example"> |
---|
2746 | Server: CERN/3.0 libwww/2.17 |
---|
2747 | </artwork></figure> |
---|
2748 | <t> |
---|
2749 | If the response is being forwarded through a proxy, the proxy |
---|
2750 | application &MUST-NOT; modify the Server header field. Instead, it |
---|
2751 | &MUST; include a Via field (as described in &header-via;). |
---|
2752 | </t> |
---|
2753 | <x:note> |
---|
2754 | <t> |
---|
2755 | <x:h>Note:</x:h> Revealing the specific software version of the server might |
---|
2756 | allow the server machine to become more vulnerable to attacks |
---|
2757 | against software that is known to contain security holes. Server |
---|
2758 | implementors are encouraged to make this field a configurable |
---|
2759 | option. |
---|
2760 | </t> |
---|
2761 | </x:note> |
---|
2762 | </section> |
---|
2763 | |
---|
2764 | <section title="User-Agent" anchor="header.user-agent"> |
---|
2765 | <iref primary="true" item="User-Agent header field" x:for-anchor=""/> |
---|
2766 | <iref primary="true" item="Header Fields" subitem="User-Agent" x:for-anchor=""/> |
---|
2767 | <x:anchor-alias value="User-Agent"/> |
---|
2768 | <t> |
---|
2769 | The "User-Agent" header field contains information about the user |
---|
2770 | agent originating the request. User agents &SHOULD; include this field with |
---|
2771 | requests. |
---|
2772 | </t> |
---|
2773 | <t> |
---|
2774 | Typically, it is used for statistical purposes, the tracing of protocol |
---|
2775 | violations, and tailoring responses to avoid particular user agent |
---|
2776 | limitations. |
---|
2777 | </t> |
---|
2778 | <t> |
---|
2779 | The field can contain multiple |
---|
2780 | product tokens (<xref target="product.tokens"/>) |
---|
2781 | and comments (&header-fields;) identifying the agent and its |
---|
2782 | significant subproducts. By convention, the product tokens are listed in |
---|
2783 | order of their significance for identifying the application. |
---|
2784 | </t> |
---|
2785 | <t> |
---|
2786 | Because this field is usually sent on every request a user agent makes, |
---|
2787 | implementations are encouraged not to include needlessly fine-grained |
---|
2788 | detail, and to limit (or even prohibit) the addition of subproducts by third |
---|
2789 | parties. Overly long and detailed User-Agent field values make requests |
---|
2790 | larger and can also be used to identify ("fingerprint") the user against |
---|
2791 | their wishes. |
---|
2792 | </t> |
---|
2793 | <t> |
---|
2794 | Likewise, implementations are encouraged not to use the product tokens of |
---|
2795 | other implementations in order to declare compatibility with them, as this |
---|
2796 | circumvents the purpose of the field. Finally, they are encouraged not to |
---|
2797 | use comments to identify products; doing so makes the field value more |
---|
2798 | difficult to parse. |
---|
2799 | </t> |
---|
2800 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/> |
---|
2801 | <x:ref>User-Agent</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) ) |
---|
2802 | </artwork></figure> |
---|
2803 | <t> |
---|
2804 | Example: |
---|
2805 | </t> |
---|
2806 | <figure><artwork type="example"> |
---|
2807 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
2808 | </artwork></figure> |
---|
2809 | </section> |
---|
2810 | |
---|
2811 | </section> |
---|
2812 | |
---|
2813 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
2814 | |
---|
2815 | <section title="Method Registry" anchor="method.registration"> |
---|
2816 | <t> |
---|
2817 | The registration procedure for HTTP request methods is defined by |
---|
2818 | <xref target="method.registry"/> of this document. |
---|
2819 | </t> |
---|
2820 | <t> |
---|
2821 | The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/> |
---|
2822 | and be populated with the registrations below: |
---|
2823 | </t> |
---|
2824 | <?BEGININC p2-semantics.iana-methods ?> |
---|
2825 | <!--AUTOGENERATED FROM extract-method-defs.xslt, do not edit manually--> |
---|
2826 | <texttable align="left" suppress-title="true" anchor="iana.method.registration.table"> |
---|
2827 | <ttcol>Method</ttcol> |
---|
2828 | <ttcol>Safe</ttcol> |
---|
2829 | <ttcol>Reference</ttcol> |
---|
2830 | <c>CONNECT</c> |
---|
2831 | <c>no</c> |
---|
2832 | <c> |
---|
2833 | <xref target="CONNECT"/> |
---|
2834 | </c> |
---|
2835 | <c>DELETE</c> |
---|
2836 | <c>no</c> |
---|
2837 | <c> |
---|
2838 | <xref target="DELETE"/> |
---|
2839 | </c> |
---|
2840 | <c>GET</c> |
---|
2841 | <c>yes</c> |
---|
2842 | <c> |
---|
2843 | <xref target="GET"/> |
---|
2844 | </c> |
---|
2845 | <c>HEAD</c> |
---|
2846 | <c>yes</c> |
---|
2847 | <c> |
---|
2848 | <xref target="HEAD"/> |
---|
2849 | </c> |
---|
2850 | <c>OPTIONS</c> |
---|
2851 | <c>yes</c> |
---|
2852 | <c> |
---|
2853 | <xref target="OPTIONS"/> |
---|
2854 | </c> |
---|
2855 | <c>POST</c> |
---|
2856 | <c>no</c> |
---|
2857 | <c> |
---|
2858 | <xref target="POST"/> |
---|
2859 | </c> |
---|
2860 | <c>PUT</c> |
---|
2861 | <c>no</c> |
---|
2862 | <c> |
---|
2863 | <xref target="PUT"/> |
---|
2864 | </c> |
---|
2865 | <c>TRACE</c> |
---|
2866 | <c>yes</c> |
---|
2867 | <c> |
---|
2868 | <xref target="TRACE"/> |
---|
2869 | </c> |
---|
2870 | </texttable> |
---|
2871 | <!--(END)--> |
---|
2872 | <?ENDINC p2-semantics.iana-methods ?> |
---|
2873 | </section> |
---|
2874 | |
---|
2875 | <section title="Status Code Registry" anchor="status.code.registration"> |
---|
2876 | <t> |
---|
2877 | The registration procedure for HTTP Status Codes — previously defined |
---|
2878 | in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> — is now defined |
---|
2879 | by <xref target="status.code.registry"/> of this document. |
---|
2880 | </t> |
---|
2881 | <t> |
---|
2882 | The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> |
---|
2883 | shall be updated with the registrations below: |
---|
2884 | </t> |
---|
2885 | <?BEGININC p2-semantics.iana-status-codes ?> |
---|
2886 | <!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually--> |
---|
2887 | <texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table"> |
---|
2888 | <ttcol>Value</ttcol> |
---|
2889 | <ttcol>Description</ttcol> |
---|
2890 | <ttcol>Reference</ttcol> |
---|
2891 | <c>100</c> |
---|
2892 | <c>Continue</c> |
---|
2893 | <c> |
---|
2894 | <xref target="status.100"/> |
---|
2895 | </c> |
---|
2896 | <c>101</c> |
---|
2897 | <c>Switching Protocols</c> |
---|
2898 | <c> |
---|
2899 | <xref target="status.101"/> |
---|
2900 | </c> |
---|
2901 | <c>200</c> |
---|
2902 | <c>OK</c> |
---|
2903 | <c> |
---|
2904 | <xref target="status.200"/> |
---|
2905 | </c> |
---|
2906 | <c>201</c> |
---|
2907 | <c>Created</c> |
---|
2908 | <c> |
---|
2909 | <xref target="status.201"/> |
---|
2910 | </c> |
---|
2911 | <c>202</c> |
---|
2912 | <c>Accepted</c> |
---|
2913 | <c> |
---|
2914 | <xref target="status.202"/> |
---|
2915 | </c> |
---|
2916 | <c>203</c> |
---|
2917 | <c>Non-Authoritative Information</c> |
---|
2918 | <c> |
---|
2919 | <xref target="status.203"/> |
---|
2920 | </c> |
---|
2921 | <c>204</c> |
---|
2922 | <c>No Content</c> |
---|
2923 | <c> |
---|
2924 | <xref target="status.204"/> |
---|
2925 | </c> |
---|
2926 | <c>205</c> |
---|
2927 | <c>Reset Content</c> |
---|
2928 | <c> |
---|
2929 | <xref target="status.205"/> |
---|
2930 | </c> |
---|
2931 | <c>300</c> |
---|
2932 | <c>Multiple Choices</c> |
---|
2933 | <c> |
---|
2934 | <xref target="status.300"/> |
---|
2935 | </c> |
---|
2936 | <c>301</c> |
---|
2937 | <c>Moved Permanently</c> |
---|
2938 | <c> |
---|
2939 | <xref target="status.301"/> |
---|
2940 | </c> |
---|
2941 | <c>302</c> |
---|
2942 | <c>Found</c> |
---|
2943 | <c> |
---|
2944 | <xref target="status.302"/> |
---|
2945 | </c> |
---|
2946 | <c>303</c> |
---|
2947 | <c>See Other</c> |
---|
2948 | <c> |
---|
2949 | <xref target="status.303"/> |
---|
2950 | </c> |
---|
2951 | <c>305</c> |
---|
2952 | <c>Use Proxy</c> |
---|
2953 | <c> |
---|
2954 | <xref target="status.305"/> |
---|
2955 | </c> |
---|
2956 | <c>306</c> |
---|
2957 | <c>(Unused)</c> |
---|
2958 | <c> |
---|
2959 | <xref target="status.306"/> |
---|
2960 | </c> |
---|
2961 | <c>307</c> |
---|
2962 | <c>Temporary Redirect</c> |
---|
2963 | <c> |
---|
2964 | <xref target="status.307"/> |
---|
2965 | </c> |
---|
2966 | <c>400</c> |
---|
2967 | <c>Bad Request</c> |
---|
2968 | <c> |
---|
2969 | <xref target="status.400"/> |
---|
2970 | </c> |
---|
2971 | <c>402</c> |
---|
2972 | <c>Payment Required</c> |
---|
2973 | <c> |
---|
2974 | <xref target="status.402"/> |
---|
2975 | </c> |
---|
2976 | <c>403</c> |
---|
2977 | <c>Forbidden</c> |
---|
2978 | <c> |
---|
2979 | <xref target="status.403"/> |
---|
2980 | </c> |
---|
2981 | <c>404</c> |
---|
2982 | <c>Not Found</c> |
---|
2983 | <c> |
---|
2984 | <xref target="status.404"/> |
---|
2985 | </c> |
---|
2986 | <c>405</c> |
---|
2987 | <c>Method Not Allowed</c> |
---|
2988 | <c> |
---|
2989 | <xref target="status.405"/> |
---|
2990 | </c> |
---|
2991 | <c>406</c> |
---|
2992 | <c>Not Acceptable</c> |
---|
2993 | <c> |
---|
2994 | <xref target="status.406"/> |
---|
2995 | </c> |
---|
2996 | <c>408</c> |
---|
2997 | <c>Request Timeout</c> |
---|
2998 | <c> |
---|
2999 | <xref target="status.408"/> |
---|
3000 | </c> |
---|
3001 | <c>409</c> |
---|
3002 | <c>Conflict</c> |
---|
3003 | <c> |
---|
3004 | <xref target="status.409"/> |
---|
3005 | </c> |
---|
3006 | <c>410</c> |
---|
3007 | <c>Gone</c> |
---|
3008 | <c> |
---|
3009 | <xref target="status.410"/> |
---|
3010 | </c> |
---|
3011 | <c>411</c> |
---|
3012 | <c>Length Required</c> |
---|
3013 | <c> |
---|
3014 | <xref target="status.411"/> |
---|
3015 | </c> |
---|
3016 | <c>413</c> |
---|
3017 | <c>Request Representation Too Large</c> |
---|
3018 | <c> |
---|
3019 | <xref target="status.413"/> |
---|
3020 | </c> |
---|
3021 | <c>414</c> |
---|
3022 | <c>URI Too Long</c> |
---|
3023 | <c> |
---|
3024 | <xref target="status.414"/> |
---|
3025 | </c> |
---|
3026 | <c>415</c> |
---|
3027 | <c>Unsupported Media Type</c> |
---|
3028 | <c> |
---|
3029 | <xref target="status.415"/> |
---|
3030 | </c> |
---|
3031 | <c>417</c> |
---|
3032 | <c>Expectation Failed</c> |
---|
3033 | <c> |
---|
3034 | <xref target="status.417"/> |
---|
3035 | </c> |
---|
3036 | <c>426</c> |
---|
3037 | <c>Upgrade Required</c> |
---|
3038 | <c> |
---|
3039 | <xref target="status.426"/> |
---|
3040 | </c> |
---|
3041 | <c>500</c> |
---|
3042 | <c>Internal Server Error</c> |
---|
3043 | <c> |
---|
3044 | <xref target="status.500"/> |
---|
3045 | </c> |
---|
3046 | <c>501</c> |
---|
3047 | <c>Not Implemented</c> |
---|
3048 | <c> |
---|
3049 | <xref target="status.501"/> |
---|
3050 | </c> |
---|
3051 | <c>502</c> |
---|
3052 | <c>Bad Gateway</c> |
---|
3053 | <c> |
---|
3054 | <xref target="status.502"/> |
---|
3055 | </c> |
---|
3056 | <c>503</c> |
---|
3057 | <c>Service Unavailable</c> |
---|
3058 | <c> |
---|
3059 | <xref target="status.503"/> |
---|
3060 | </c> |
---|
3061 | <c>504</c> |
---|
3062 | <c>Gateway Timeout</c> |
---|
3063 | <c> |
---|
3064 | <xref target="status.504"/> |
---|
3065 | </c> |
---|
3066 | <c>505</c> |
---|
3067 | <c>HTTP Version Not Supported</c> |
---|
3068 | <c> |
---|
3069 | <xref target="status.505"/> |
---|
3070 | </c> |
---|
3071 | </texttable> |
---|
3072 | <!--(END)--> |
---|
3073 | <?ENDINC p2-semantics.iana-status-codes ?> |
---|
3074 | </section> |
---|
3075 | <section title="Header Field Registration" anchor="header.field.registration"> |
---|
3076 | <t> |
---|
3077 | The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated |
---|
3078 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
3079 | </t> |
---|
3080 | <?BEGININC p2-semantics.iana-headers ?> |
---|
3081 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
3082 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
3083 | <ttcol>Header Field Name</ttcol> |
---|
3084 | <ttcol>Protocol</ttcol> |
---|
3085 | <ttcol>Status</ttcol> |
---|
3086 | <ttcol>Reference</ttcol> |
---|
3087 | |
---|
3088 | <c>Allow</c> |
---|
3089 | <c>http</c> |
---|
3090 | <c>standard</c> |
---|
3091 | <c> |
---|
3092 | <xref target="header.allow"/> |
---|
3093 | </c> |
---|
3094 | <c>Date</c> |
---|
3095 | <c>http</c> |
---|
3096 | <c>standard</c> |
---|
3097 | <c> |
---|
3098 | <xref target="header.date"/> |
---|
3099 | </c> |
---|
3100 | <c>Expect</c> |
---|
3101 | <c>http</c> |
---|
3102 | <c>standard</c> |
---|
3103 | <c> |
---|
3104 | <xref target="header.expect"/> |
---|
3105 | </c> |
---|
3106 | <c>From</c> |
---|
3107 | <c>http</c> |
---|
3108 | <c>standard</c> |
---|
3109 | <c> |
---|
3110 | <xref target="header.from"/> |
---|
3111 | </c> |
---|
3112 | <c>Location</c> |
---|
3113 | <c>http</c> |
---|
3114 | <c>standard</c> |
---|
3115 | <c> |
---|
3116 | <xref target="header.location"/> |
---|
3117 | </c> |
---|
3118 | <c>Max-Forwards</c> |
---|
3119 | <c>http</c> |
---|
3120 | <c>standard</c> |
---|
3121 | <c> |
---|
3122 | <xref target="header.max-forwards"/> |
---|
3123 | </c> |
---|
3124 | <c>Referer</c> |
---|
3125 | <c>http</c> |
---|
3126 | <c>standard</c> |
---|
3127 | <c> |
---|
3128 | <xref target="header.referer"/> |
---|
3129 | </c> |
---|
3130 | <c>Retry-After</c> |
---|
3131 | <c>http</c> |
---|
3132 | <c>standard</c> |
---|
3133 | <c> |
---|
3134 | <xref target="header.retry-after"/> |
---|
3135 | </c> |
---|
3136 | <c>Server</c> |
---|
3137 | <c>http</c> |
---|
3138 | <c>standard</c> |
---|
3139 | <c> |
---|
3140 | <xref target="header.server"/> |
---|
3141 | </c> |
---|
3142 | <c>User-Agent</c> |
---|
3143 | <c>http</c> |
---|
3144 | <c>standard</c> |
---|
3145 | <c> |
---|
3146 | <xref target="header.user-agent"/> |
---|
3147 | </c> |
---|
3148 | </texttable> |
---|
3149 | <!--(END)--> |
---|
3150 | <?ENDINC p2-semantics.iana-headers ?> |
---|
3151 | <t> |
---|
3152 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
3153 | </t> |
---|
3154 | </section> |
---|
3155 | </section> |
---|
3156 | |
---|
3157 | <section title="Security Considerations" anchor="security.considerations"> |
---|
3158 | <t> |
---|
3159 | This section is meant to inform application developers, information |
---|
3160 | providers, and users of the security limitations in HTTP/1.1 as |
---|
3161 | described by this document. The discussion does not include |
---|
3162 | definitive solutions to the problems revealed, though it does make |
---|
3163 | some suggestions for reducing security risks. |
---|
3164 | </t> |
---|
3165 | |
---|
3166 | <section title="Transfer of Sensitive Information" anchor="security.sensitive"> |
---|
3167 | <t> |
---|
3168 | Like any generic data transfer protocol, HTTP cannot regulate the |
---|
3169 | content of the data that is transferred, nor is there any a priori |
---|
3170 | method of determining the sensitivity of any particular piece of |
---|
3171 | information within the context of any given request. Therefore, |
---|
3172 | applications &SHOULD; supply as much control over this information as |
---|
3173 | possible to the provider of that information. Four header fields are |
---|
3174 | worth special mention in this context: Server, Via, Referer and From. |
---|
3175 | </t> |
---|
3176 | <t> |
---|
3177 | Revealing the specific software version of the server might allow the |
---|
3178 | server machine to become more vulnerable to attacks against software |
---|
3179 | that is known to contain security holes. Implementors &SHOULD; make the |
---|
3180 | Server header field a configurable option. |
---|
3181 | </t> |
---|
3182 | <t> |
---|
3183 | Proxies which serve as a portal through a network firewall &SHOULD; |
---|
3184 | take special precautions regarding the transfer of header information |
---|
3185 | that identifies the hosts behind the firewall. In particular, they |
---|
3186 | &SHOULD; remove, or replace with sanitized versions, any Via fields |
---|
3187 | generated behind the firewall. |
---|
3188 | </t> |
---|
3189 | <t> |
---|
3190 | The Referer header field allows reading patterns to be studied and reverse |
---|
3191 | links drawn. Although it can be very useful, its power can be abused |
---|
3192 | if user details are not separated from the information contained in |
---|
3193 | the Referer. Even when the personal information has been removed, the |
---|
3194 | Referer header field might indicate a private document's URI whose |
---|
3195 | publication would be inappropriate. |
---|
3196 | </t> |
---|
3197 | <t> |
---|
3198 | The information sent in the From field might conflict with the user's |
---|
3199 | privacy interests or their site's security policy, and hence it |
---|
3200 | &SHOULD-NOT; be transmitted without the user being able to disable, |
---|
3201 | enable, and modify the contents of the field. The user &MUST; be able |
---|
3202 | to set the contents of this field within a user preference or |
---|
3203 | application defaults configuration. |
---|
3204 | </t> |
---|
3205 | <t> |
---|
3206 | We suggest, though do not require, that a convenient toggle interface |
---|
3207 | be provided for the user to enable or disable the sending of From and |
---|
3208 | Referer information. |
---|
3209 | </t> |
---|
3210 | <t> |
---|
3211 | The User-Agent (<xref target="header.user-agent"/>) or Server (<xref |
---|
3212 | target="header.server"/>) header fields can sometimes be used to determine |
---|
3213 | that a specific client or server has a particular security hole which might |
---|
3214 | be exploited. Unfortunately, this same information is often used for other |
---|
3215 | valuable purposes for which HTTP currently has no better mechanism. |
---|
3216 | </t> |
---|
3217 | <t> |
---|
3218 | Furthermore, the User-Agent header field may contain enough entropy to be |
---|
3219 | used, possibly in conjunction with other material, to uniquely identify the |
---|
3220 | user. |
---|
3221 | </t> |
---|
3222 | <t> |
---|
3223 | Some request methods, like TRACE (<xref target="TRACE"/>), expose information |
---|
3224 | that was sent in request header fields within the body of their response. |
---|
3225 | Clients &SHOULD; be careful with sensitive information, like Cookies, |
---|
3226 | Authorization credentials, and other header fields that might be used to |
---|
3227 | collect data from the client. |
---|
3228 | </t> |
---|
3229 | </section> |
---|
3230 | |
---|
3231 | <section title="Encoding Sensitive Information in URIs" anchor="encoding.sensitive.information.in.uris"> |
---|
3232 | <t> |
---|
3233 | Because the source of a link might be private information or might |
---|
3234 | reveal an otherwise private information source, it is strongly |
---|
3235 | recommended that the user be able to select whether or not the |
---|
3236 | Referer field is sent. For example, a browser client could have a |
---|
3237 | toggle switch for browsing openly/anonymously, which would |
---|
3238 | respectively enable/disable the sending of Referer and From |
---|
3239 | information. |
---|
3240 | </t> |
---|
3241 | <t> |
---|
3242 | Clients &SHOULD-NOT; include a Referer header field in a (non-secure) |
---|
3243 | HTTP request if the referring page was transferred with a secure |
---|
3244 | protocol. |
---|
3245 | </t> |
---|
3246 | <t> |
---|
3247 | Authors of services &SHOULD-NOT; use GET-based forms for the submission of |
---|
3248 | sensitive data because that data will be placed in the request-target. Many |
---|
3249 | existing servers, proxies, and user agents log or display the request-target |
---|
3250 | in places where it might be visible to third parties. Such services can |
---|
3251 | use POST-based form submission instead. |
---|
3252 | </t> |
---|
3253 | </section> |
---|
3254 | |
---|
3255 | <section title="Location Header Fields: Spoofing and Information Leakage" anchor="location.spoofing-leakage"> |
---|
3256 | <t> |
---|
3257 | If a single server supports multiple organizations that do not trust |
---|
3258 | one another, then it &MUST; check the values of Location and Content-Location |
---|
3259 | header fields in responses that are generated under control of |
---|
3260 | said organizations to make sure that they do not attempt to |
---|
3261 | invalidate resources over which they have no authority. |
---|
3262 | </t> |
---|
3263 | <t> |
---|
3264 | Furthermore, appending the fragment identifier from one URI to another |
---|
3265 | one obtained from a Location header field might leak confidential |
---|
3266 | information to the target server — although the fragment identifier is |
---|
3267 | not transmitted in the final request, it might be visible to the user agent |
---|
3268 | through other means, such as scripting. |
---|
3269 | </t> |
---|
3270 | </section> |
---|
3271 | |
---|
3272 | <section title="Security Considerations for CONNECT"> |
---|
3273 | <t> |
---|
3274 | Since tunneled data is opaque to the proxy, there are additional |
---|
3275 | risks to tunneling to other well-known or reserved ports. |
---|
3276 | A HTTP client CONNECTing to port 25 could relay spam |
---|
3277 | via SMTP, for example. As such, proxies &SHOULD; restrict CONNECT |
---|
3278 | access to a small number of known ports. |
---|
3279 | </t> |
---|
3280 | </section> |
---|
3281 | |
---|
3282 | </section> |
---|
3283 | |
---|
3284 | <section title="Acknowledgments" anchor="acks"> |
---|
3285 | <t> |
---|
3286 | See &acks;. |
---|
3287 | </t> |
---|
3288 | </section> |
---|
3289 | </middle> |
---|
3290 | <back> |
---|
3291 | |
---|
3292 | <references title="Normative References"> |
---|
3293 | |
---|
3294 | <reference anchor="Part1"> |
---|
3295 | <front> |
---|
3296 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
3297 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3298 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
3299 | <address><email>fielding@gbiv.com</email></address> |
---|
3300 | </author> |
---|
3301 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3302 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3303 | <address><email>ylafon@w3.org</email></address> |
---|
3304 | </author> |
---|
3305 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3306 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3307 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3308 | </author> |
---|
3309 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
3310 | </front> |
---|
3311 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> |
---|
3312 | <x:source href="p1-messaging.xml" basename="p1-messaging"/> |
---|
3313 | </reference> |
---|
3314 | |
---|
3315 | <reference anchor="Part3"> |
---|
3316 | <front> |
---|
3317 | <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> |
---|
3318 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3319 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
3320 | <address><email>fielding@gbiv.com</email></address> |
---|
3321 | </author> |
---|
3322 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3323 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3324 | <address><email>ylafon@w3.org</email></address> |
---|
3325 | </author> |
---|
3326 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3327 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3328 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3329 | </author> |
---|
3330 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
3331 | </front> |
---|
3332 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/> |
---|
3333 | <x:source href="p3-payload.xml" basename="p3-payload"/> |
---|
3334 | </reference> |
---|
3335 | |
---|
3336 | <reference anchor="Part4"> |
---|
3337 | <front> |
---|
3338 | <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> |
---|
3339 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3340 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
3341 | <address><email>fielding@gbiv.com</email></address> |
---|
3342 | </author> |
---|
3343 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3344 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3345 | <address><email>ylafon@w3.org</email></address> |
---|
3346 | </author> |
---|
3347 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3348 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3349 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3350 | </author> |
---|
3351 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
3352 | </front> |
---|
3353 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/> |
---|
3354 | <x:source href="p4-conditional.xml" basename="p4-conditional"/> |
---|
3355 | </reference> |
---|
3356 | |
---|
3357 | <reference anchor="Part5"> |
---|
3358 | <front> |
---|
3359 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
3360 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3361 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
3362 | <address><email>fielding@gbiv.com</email></address> |
---|
3363 | </author> |
---|
3364 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3365 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3366 | <address><email>ylafon@w3.org</email></address> |
---|
3367 | </author> |
---|
3368 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3369 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3370 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3371 | </author> |
---|
3372 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
3373 | </front> |
---|
3374 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/> |
---|
3375 | <x:source href="p5-range.xml" basename="p5-range"/> |
---|
3376 | </reference> |
---|
3377 | |
---|
3378 | <reference anchor="Part6"> |
---|
3379 | <front> |
---|
3380 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
3381 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3382 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
3383 | <address><email>fielding@gbiv.com</email></address> |
---|
3384 | </author> |
---|
3385 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3386 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3387 | <address><email>ylafon@w3.org</email></address> |
---|
3388 | </author> |
---|
3389 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
3390 | <organization>Rackspace</organization> |
---|
3391 | <address><email>mnot@mnot.net</email></address> |
---|
3392 | </author> |
---|
3393 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3394 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3395 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3396 | </author> |
---|
3397 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
3398 | </front> |
---|
3399 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> |
---|
3400 | <x:source href="p6-cache.xml" basename="p6-cache"/> |
---|
3401 | </reference> |
---|
3402 | |
---|
3403 | <reference anchor="Part7"> |
---|
3404 | <front> |
---|
3405 | <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title> |
---|
3406 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3407 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
3408 | <address><email>fielding@gbiv.com</email></address> |
---|
3409 | </author> |
---|
3410 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3411 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3412 | <address><email>ylafon@w3.org</email></address> |
---|
3413 | </author> |
---|
3414 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3415 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3416 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3417 | </author> |
---|
3418 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
3419 | </front> |
---|
3420 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/> |
---|
3421 | <x:source href="p7-auth.xml" basename="p7-auth"/> |
---|
3422 | </reference> |
---|
3423 | |
---|
3424 | <reference anchor="RFC1950"> |
---|
3425 | <front> |
---|
3426 | <title>ZLIB Compressed Data Format Specification version 3.3</title> |
---|
3427 | <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
3428 | <organization>Aladdin Enterprises</organization> |
---|
3429 | <address><email>ghost@aladdin.com</email></address> |
---|
3430 | </author> |
---|
3431 | <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"/> |
---|
3432 | <date month="May" year="1996"/> |
---|
3433 | </front> |
---|
3434 | <seriesInfo name="RFC" value="1950"/> |
---|
3435 | <!--<annotation> |
---|
3436 | RFC 1950 is an Informational RFC, thus it might be less stable than |
---|
3437 | this specification. On the other hand, this downward reference was |
---|
3438 | present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997, |
---|
3439 | therefore it is unlikely to cause problems in practice. See also |
---|
3440 | <xref target="BCP97"/>. |
---|
3441 | </annotation>--> |
---|
3442 | </reference> |
---|
3443 | |
---|
3444 | <reference anchor="RFC1951"> |
---|
3445 | <front> |
---|
3446 | <title>DEFLATE Compressed Data Format Specification version 1.3</title> |
---|
3447 | <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
3448 | <organization>Aladdin Enterprises</organization> |
---|
3449 | <address><email>ghost@aladdin.com</email></address> |
---|
3450 | </author> |
---|
3451 | <date month="May" year="1996"/> |
---|
3452 | </front> |
---|
3453 | <seriesInfo name="RFC" value="1951"/> |
---|
3454 | <!--<annotation> |
---|
3455 | RFC 1951 is an Informational RFC, thus it might be less stable than |
---|
3456 | this specification. On the other hand, this downward reference was |
---|
3457 | present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997, |
---|
3458 | therefore it is unlikely to cause problems in practice. See also |
---|
3459 | <xref target="BCP97"/>. |
---|
3460 | </annotation>--> |
---|
3461 | </reference> |
---|
3462 | |
---|
3463 | <reference anchor="RFC1952"> |
---|
3464 | <front> |
---|
3465 | <title>GZIP file format specification version 4.3</title> |
---|
3466 | <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
3467 | <organization>Aladdin Enterprises</organization> |
---|
3468 | <address><email>ghost@aladdin.com</email></address> |
---|
3469 | </author> |
---|
3470 | <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"> |
---|
3471 | <address><email>gzip@prep.ai.mit.edu</email></address> |
---|
3472 | </author> |
---|
3473 | <author initials="M." surname="Adler" fullname="Mark Adler"> |
---|
3474 | <address><email>madler@alumni.caltech.edu</email></address> |
---|
3475 | </author> |
---|
3476 | <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
3477 | <address><email>ghost@aladdin.com</email></address> |
---|
3478 | </author> |
---|
3479 | <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson"> |
---|
3480 | <address><email>randeg@alumni.rpi.edu</email></address> |
---|
3481 | </author> |
---|
3482 | <date month="May" year="1996"/> |
---|
3483 | </front> |
---|
3484 | <seriesInfo name="RFC" value="1952"/> |
---|
3485 | <!--<annotation> |
---|
3486 | RFC 1952 is an Informational RFC, thus it might be less stable than |
---|
3487 | this specification. On the other hand, this downward reference was |
---|
3488 | present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997, |
---|
3489 | therefore it is unlikely to cause problems in practice. See also |
---|
3490 | <xref target="BCP97"/>. |
---|
3491 | </annotation>--> |
---|
3492 | </reference> |
---|
3493 | |
---|
3494 | <reference anchor="RFC2045"> |
---|
3495 | <front> |
---|
3496 | <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> |
---|
3497 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
3498 | <organization>Innosoft International, Inc.</organization> |
---|
3499 | <address><email>ned@innosoft.com</email></address> |
---|
3500 | </author> |
---|
3501 | <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
3502 | <organization>First Virtual Holdings</organization> |
---|
3503 | <address><email>nsb@nsb.fv.com</email></address> |
---|
3504 | </author> |
---|
3505 | <date month="November" year="1996"/> |
---|
3506 | </front> |
---|
3507 | <seriesInfo name="RFC" value="2045"/> |
---|
3508 | </reference> |
---|
3509 | |
---|
3510 | <reference anchor="RFC2046"> |
---|
3511 | <front> |
---|
3512 | <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> |
---|
3513 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
3514 | <organization>Innosoft International, Inc.</organization> |
---|
3515 | <address><email>ned@innosoft.com</email></address> |
---|
3516 | </author> |
---|
3517 | <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
3518 | <organization>First Virtual Holdings</organization> |
---|
3519 | <address><email>nsb@nsb.fv.com</email></address> |
---|
3520 | </author> |
---|
3521 | <date month="November" year="1996"/> |
---|
3522 | </front> |
---|
3523 | <seriesInfo name="RFC" value="2046"/> |
---|
3524 | </reference> |
---|
3525 | |
---|
3526 | <reference anchor="RFC2119"> |
---|
3527 | <front> |
---|
3528 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
3529 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
3530 | <organization>Harvard University</organization> |
---|
3531 | <address><email>sob@harvard.edu</email></address> |
---|
3532 | </author> |
---|
3533 | <date month="March" year="1997"/> |
---|
3534 | </front> |
---|
3535 | <seriesInfo name="BCP" value="14"/> |
---|
3536 | <seriesInfo name="RFC" value="2119"/> |
---|
3537 | </reference> |
---|
3538 | |
---|
3539 | <reference anchor="RFC3986"> |
---|
3540 | <front> |
---|
3541 | <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title> |
---|
3542 | <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'> |
---|
3543 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
3544 | <address> |
---|
3545 | <email>timbl@w3.org</email> |
---|
3546 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
3547 | </address> |
---|
3548 | </author> |
---|
3549 | <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'> |
---|
3550 | <organization abbrev="Day Software">Day Software</organization> |
---|
3551 | <address> |
---|
3552 | <email>fielding@gbiv.com</email> |
---|
3553 | <uri>http://roy.gbiv.com/</uri> |
---|
3554 | </address> |
---|
3555 | </author> |
---|
3556 | <author initials='L.' surname='Masinter' fullname='Larry Masinter'> |
---|
3557 | <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> |
---|
3558 | <address> |
---|
3559 | <email>LMM@acm.org</email> |
---|
3560 | <uri>http://larry.masinter.net/</uri> |
---|
3561 | </address> |
---|
3562 | </author> |
---|
3563 | <date month='January' year='2005'></date> |
---|
3564 | </front> |
---|
3565 | <seriesInfo name="STD" value="66"/> |
---|
3566 | <seriesInfo name="RFC" value="3986"/> |
---|
3567 | </reference> |
---|
3568 | |
---|
3569 | <reference anchor='RFC4647'> |
---|
3570 | <front> |
---|
3571 | <title>Matching of Language Tags</title> |
---|
3572 | <author initials='A.' surname='Phillips' fullname='Addison Phillips' role="editor"> |
---|
3573 | <organization>Yahoo! Inc.</organization> |
---|
3574 | <address><email>addison@inter-locale.com</email></address> |
---|
3575 | </author> |
---|
3576 | <author initials='M.' surname='Davis' fullname='Mark Davis' role="editor"> |
---|
3577 | <organization>Google</organization> |
---|
3578 | <address><email>mark.davis@macchiato.com</email></address> |
---|
3579 | </author> |
---|
3580 | <date year='2006' month='September' /> |
---|
3581 | </front> |
---|
3582 | <seriesInfo name='BCP' value='47' /> |
---|
3583 | <seriesInfo name='RFC' value='4647' /> |
---|
3584 | </reference> |
---|
3585 | |
---|
3586 | <reference anchor="RFC5234"> |
---|
3587 | <front> |
---|
3588 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
3589 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
3590 | <organization>Brandenburg InternetWorking</organization> |
---|
3591 | <address> |
---|
3592 | <email>dcrocker@bbiw.net</email> |
---|
3593 | </address> |
---|
3594 | </author> |
---|
3595 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
3596 | <organization>THUS plc.</organization> |
---|
3597 | <address> |
---|
3598 | <email>paul.overell@thus.net</email> |
---|
3599 | </address> |
---|
3600 | </author> |
---|
3601 | <date month="January" year="2008"/> |
---|
3602 | </front> |
---|
3603 | <seriesInfo name="STD" value="68"/> |
---|
3604 | <seriesInfo name="RFC" value="5234"/> |
---|
3605 | </reference> |
---|
3606 | |
---|
3607 | <reference anchor='RFC5646'> |
---|
3608 | <front> |
---|
3609 | <title>Tags for Identifying Languages</title> |
---|
3610 | <author initials='A.' surname='Phillips' fullname='Addison Phillips' role='editor'> |
---|
3611 | <organization>Lab126</organization> |
---|
3612 | <address><email>addison@inter-locale.com</email></address> |
---|
3613 | </author> |
---|
3614 | <author initials='M.' surname='Davis' fullname='Mark Davis' role='editor'> |
---|
3615 | <organization>Google</organization> |
---|
3616 | <address><email>mark.davis@google.com</email></address> |
---|
3617 | </author> |
---|
3618 | <date month='September' year='2009' /> |
---|
3619 | </front> |
---|
3620 | <seriesInfo name='BCP' value='47' /> |
---|
3621 | <seriesInfo name='RFC' value='5646' /> |
---|
3622 | </reference> |
---|
3623 | |
---|
3624 | </references> |
---|
3625 | |
---|
3626 | <references title="Informative References"> |
---|
3627 | |
---|
3628 | <reference anchor="RFC1123"> |
---|
3629 | <front> |
---|
3630 | <title>Requirements for Internet Hosts - Application and Support</title> |
---|
3631 | <author initials="R." surname="Braden" fullname="Robert Braden"> |
---|
3632 | <organization>University of Southern California (USC), Information Sciences Institute</organization> |
---|
3633 | <address><email>Braden@ISI.EDU</email></address> |
---|
3634 | </author> |
---|
3635 | <date month="October" year="1989"/> |
---|
3636 | </front> |
---|
3637 | <seriesInfo name="STD" value="3"/> |
---|
3638 | <seriesInfo name="RFC" value="1123"/> |
---|
3639 | </reference> |
---|
3640 | |
---|
3641 | <reference anchor="RFC1945"> |
---|
3642 | <front> |
---|
3643 | <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> |
---|
3644 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3645 | <organization>MIT, Laboratory for Computer Science</organization> |
---|
3646 | <address><email>timbl@w3.org</email></address> |
---|
3647 | </author> |
---|
3648 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
3649 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
3650 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3651 | </author> |
---|
3652 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
3653 | <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> |
---|
3654 | <address><email>frystyk@w3.org</email></address> |
---|
3655 | </author> |
---|
3656 | <date month="May" year="1996"/> |
---|
3657 | </front> |
---|
3658 | <seriesInfo name="RFC" value="1945"/> |
---|
3659 | </reference> |
---|
3660 | |
---|
3661 | <reference anchor="RFC2049"> |
---|
3662 | <front> |
---|
3663 | <title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title> |
---|
3664 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
3665 | <organization>Innosoft International, Inc.</organization> |
---|
3666 | <address><email>ned@innosoft.com</email></address> |
---|
3667 | </author> |
---|
3668 | <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
3669 | <organization>First Virtual Holdings</organization> |
---|
3670 | <address><email>nsb@nsb.fv.com</email></address> |
---|
3671 | </author> |
---|
3672 | <date month="November" year="1996"/> |
---|
3673 | </front> |
---|
3674 | <seriesInfo name="RFC" value="2049"/> |
---|
3675 | </reference> |
---|
3676 | |
---|
3677 | <reference anchor="RFC2068"> |
---|
3678 | <front> |
---|
3679 | <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
3680 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
3681 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
3682 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3683 | </author> |
---|
3684 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3685 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3686 | <address><email>jg@w3.org</email></address> |
---|
3687 | </author> |
---|
3688 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3689 | <organization>Digital Equipment Corporation, Western Research Laboratory</organization> |
---|
3690 | <address><email>mogul@wrl.dec.com</email></address> |
---|
3691 | </author> |
---|
3692 | <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
3693 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3694 | <address><email>frystyk@w3.org</email></address> |
---|
3695 | </author> |
---|
3696 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3697 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3698 | <address><email>timbl@w3.org</email></address> |
---|
3699 | </author> |
---|
3700 | <date month="January" year="1997"/> |
---|
3701 | </front> |
---|
3702 | <seriesInfo name="RFC" value="2068"/> |
---|
3703 | </reference> |
---|
3704 | |
---|
3705 | <reference anchor="RFC2076"> |
---|
3706 | <front> |
---|
3707 | <title abbrev="Internet Message Headers">Common Internet Message Headers</title> |
---|
3708 | <author initials="J." surname="Palme" fullname="Jacob Palme"> |
---|
3709 | <organization>Stockholm University/KTH</organization> |
---|
3710 | <address><email>jpalme@dsv.su.se</email></address> |
---|
3711 | </author> |
---|
3712 | <date month="February" year="1997"/> |
---|
3713 | </front> |
---|
3714 | <seriesInfo name="RFC" value="2076"/> |
---|
3715 | </reference> |
---|
3716 | |
---|
3717 | <reference anchor="RFC2277"> |
---|
3718 | <front> |
---|
3719 | <title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title> |
---|
3720 | <author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand"> |
---|
3721 | <organization>UNINETT</organization> |
---|
3722 | <address><email>Harald.T.Alvestrand@uninett.no</email></address> |
---|
3723 | </author> |
---|
3724 | <date month="January" year="1998"/> |
---|
3725 | </front> |
---|
3726 | <seriesInfo name="BCP" value="18"/> |
---|
3727 | <seriesInfo name="RFC" value="2277"/> |
---|
3728 | </reference> |
---|
3729 | |
---|
3730 | <reference anchor='RFC2295'> |
---|
3731 | <front> |
---|
3732 | <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title> |
---|
3733 | <author initials='K.' surname='Holtman' fullname='Koen Holtman'> |
---|
3734 | <organization>Technische Universiteit Eindhoven</organization> |
---|
3735 | <address> |
---|
3736 | <email>koen@win.tue.nl</email> |
---|
3737 | </address> |
---|
3738 | </author> |
---|
3739 | <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'> |
---|
3740 | <organization>Hewlett-Packard Company</organization> |
---|
3741 | <address> |
---|
3742 | <email>mutz@hpl.hp.com</email> |
---|
3743 | </address> |
---|
3744 | </author> |
---|
3745 | <date year='1998' month='March'/> |
---|
3746 | </front> |
---|
3747 | <seriesInfo name='RFC' value='2295'/> |
---|
3748 | </reference> |
---|
3749 | |
---|
3750 | <reference anchor="RFC2388"> |
---|
3751 | <front> |
---|
3752 | <title abbrev="multipart/form-data">Returning Values from Forms: multipart/form-data</title> |
---|
3753 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
3754 | <organization>Xerox Palo Alto Research Center</organization> |
---|
3755 | <address><email>masinter@parc.xerox.com</email></address> |
---|
3756 | </author> |
---|
3757 | <date year="1998" month="August"/> |
---|
3758 | </front> |
---|
3759 | <seriesInfo name="RFC" value="2388"/> |
---|
3760 | </reference> |
---|
3761 | |
---|
3762 | <reference anchor="RFC2557"> |
---|
3763 | <front> |
---|
3764 | <title abbrev="MIME Encapsulation of Aggregate Documents">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</title> |
---|
3765 | <author initials="F." surname="Palme" fullname="Jacob Palme"> |
---|
3766 | <organization>Stockholm University and KTH</organization> |
---|
3767 | <address><email>jpalme@dsv.su.se</email></address> |
---|
3768 | </author> |
---|
3769 | <author initials="A." surname="Hopmann" fullname="Alex Hopmann"> |
---|
3770 | <organization>Microsoft Corporation</organization> |
---|
3771 | <address><email>alexhop@microsoft.com</email></address> |
---|
3772 | </author> |
---|
3773 | <author initials="N." surname="Shelness" fullname="Nick Shelness"> |
---|
3774 | <organization>Lotus Development Corporation</organization> |
---|
3775 | <address><email>Shelness@lotus.com</email></address> |
---|
3776 | </author> |
---|
3777 | <author initials="E." surname="Stefferud" fullname="Einar Stefferud"> |
---|
3778 | <address><email>stef@nma.com</email></address> |
---|
3779 | </author> |
---|
3780 | <date year="1999" month="March"/> |
---|
3781 | </front> |
---|
3782 | <seriesInfo name="RFC" value="2557"/> |
---|
3783 | </reference> |
---|
3784 | |
---|
3785 | <reference anchor="RFC2616"> |
---|
3786 | <front> |
---|
3787 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
3788 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
3789 | <organization>University of California, Irvine</organization> |
---|
3790 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3791 | </author> |
---|
3792 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
3793 | <organization>W3C</organization> |
---|
3794 | <address><email>jg@w3.org</email></address> |
---|
3795 | </author> |
---|
3796 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
3797 | <organization>Compaq Computer Corporation</organization> |
---|
3798 | <address><email>mogul@wrl.dec.com</email></address> |
---|
3799 | </author> |
---|
3800 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
3801 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3802 | <address><email>frystyk@w3.org</email></address> |
---|
3803 | </author> |
---|
3804 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
3805 | <organization>Xerox Corporation</organization> |
---|
3806 | <address><email>masinter@parc.xerox.com</email></address> |
---|
3807 | </author> |
---|
3808 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
3809 | <organization>Microsoft Corporation</organization> |
---|
3810 | <address><email>paulle@microsoft.com</email></address> |
---|
3811 | </author> |
---|
3812 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
3813 | <organization>W3C</organization> |
---|
3814 | <address><email>timbl@w3.org</email></address> |
---|
3815 | </author> |
---|
3816 | <date month="June" year="1999"/> |
---|
3817 | </front> |
---|
3818 | <seriesInfo name="RFC" value="2616"/> |
---|
3819 | </reference> |
---|
3820 | |
---|
3821 | <reference anchor='RFC2817'> |
---|
3822 | <front> |
---|
3823 | <title>Upgrading to TLS Within HTTP/1.1</title> |
---|
3824 | <author initials='R.' surname='Khare' fullname='R. Khare'> |
---|
3825 | <organization>4K Associates / UC Irvine</organization> |
---|
3826 | <address><email>rohit@4K-associates.com</email></address> |
---|
3827 | </author> |
---|
3828 | <author initials='S.' surname='Lawrence' fullname='S. Lawrence'> |
---|
3829 | <organization>Agranat Systems, Inc.</organization> |
---|
3830 | <address><email>lawrence@agranat.com</email></address> |
---|
3831 | </author> |
---|
3832 | <date year='2000' month='May' /> |
---|
3833 | </front> |
---|
3834 | <seriesInfo name='RFC' value='2817' /> |
---|
3835 | </reference> |
---|
3836 | |
---|
3837 | <reference anchor="RFC3629"> |
---|
3838 | <front> |
---|
3839 | <title>UTF-8, a transformation format of ISO 10646</title> |
---|
3840 | <author initials="F." surname="Yergeau" fullname="F. Yergeau"> |
---|
3841 | <organization>Alis Technologies</organization> |
---|
3842 | <address><email>fyergeau@alis.com</email></address> |
---|
3843 | </author> |
---|
3844 | <date month="November" year="2003"/> |
---|
3845 | </front> |
---|
3846 | <seriesInfo name="STD" value="63"/> |
---|
3847 | <seriesInfo name="RFC" value="3629"/> |
---|
3848 | </reference> |
---|
3849 | |
---|
3850 | <reference anchor='RFC3864'> |
---|
3851 | <front> |
---|
3852 | <title>Registration Procedures for Message Header Fields</title> |
---|
3853 | <author initials='G.' surname='Klyne' fullname='G. Klyne'> |
---|
3854 | <organization>Nine by Nine</organization> |
---|
3855 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
3856 | </author> |
---|
3857 | <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> |
---|
3858 | <organization>BEA Systems</organization> |
---|
3859 | <address><email>mnot@pobox.com</email></address> |
---|
3860 | </author> |
---|
3861 | <author initials='J.' surname='Mogul' fullname='J. Mogul'> |
---|
3862 | <organization>HP Labs</organization> |
---|
3863 | <address><email>JeffMogul@acm.org</email></address> |
---|
3864 | </author> |
---|
3865 | <date year='2004' month='September' /> |
---|
3866 | </front> |
---|
3867 | <seriesInfo name='BCP' value='90' /> |
---|
3868 | <seriesInfo name='RFC' value='3864' /> |
---|
3869 | </reference> |
---|
3870 | |
---|
3871 | <reference anchor="RFC4288"> |
---|
3872 | <front> |
---|
3873 | <title>Media Type Specifications and Registration Procedures</title> |
---|
3874 | <author initials="N." surname="Freed" fullname="N. Freed"> |
---|
3875 | <organization>Sun Microsystems</organization> |
---|
3876 | <address> |
---|
3877 | <email>ned.freed@mrochek.com</email> |
---|
3878 | </address> |
---|
3879 | </author> |
---|
3880 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
3881 | <address> |
---|
3882 | <email>klensin+ietf@jck.com</email> |
---|
3883 | </address> |
---|
3884 | </author> |
---|
3885 | <date year="2005" month="December"/> |
---|
3886 | </front> |
---|
3887 | <seriesInfo name="BCP" value="13"/> |
---|
3888 | <seriesInfo name="RFC" value="4288"/> |
---|
3889 | </reference> |
---|
3890 | |
---|
3891 | <reference anchor='RFC5226'> |
---|
3892 | <front> |
---|
3893 | <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> |
---|
3894 | <author initials='T.' surname='Narten' fullname='T. Narten'> |
---|
3895 | <organization>IBM</organization> |
---|
3896 | <address><email>narten@us.ibm.com</email></address> |
---|
3897 | </author> |
---|
3898 | <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'> |
---|
3899 | <organization>Google</organization> |
---|
3900 | <address><email>Harald@Alvestrand.no</email></address> |
---|
3901 | </author> |
---|
3902 | <date year='2008' month='May' /> |
---|
3903 | </front> |
---|
3904 | <seriesInfo name='BCP' value='26' /> |
---|
3905 | <seriesInfo name='RFC' value='5226' /> |
---|
3906 | </reference> |
---|
3907 | |
---|
3908 | <reference anchor="RFC5322"> |
---|
3909 | <front> |
---|
3910 | <title>Internet Message Format</title> |
---|
3911 | <author initials="P." surname="Resnick" fullname="P. Resnick"> |
---|
3912 | <organization>Qualcomm Incorporated</organization> |
---|
3913 | </author> |
---|
3914 | <date year="2008" month="October"/> |
---|
3915 | </front> |
---|
3916 | <seriesInfo name="RFC" value="5322"/> |
---|
3917 | </reference> |
---|
3918 | |
---|
3919 | <reference anchor='RFC5789'> |
---|
3920 | <front> |
---|
3921 | <title>PATCH Method for HTTP</title> |
---|
3922 | <author initials='L.' surname='Dusseault' fullname='L. Dusseault'> |
---|
3923 | <organization>Linden Lab</organization> |
---|
3924 | </author> |
---|
3925 | <author initials='J.' surname='Snell' fullname='J. Snell' /> |
---|
3926 | <date year='2010' month='March' /> |
---|
3927 | </front> |
---|
3928 | <seriesInfo name='RFC' value='5789' /> |
---|
3929 | </reference> |
---|
3930 | |
---|
3931 | <reference anchor="RFC5987"> |
---|
3932 | <front> |
---|
3933 | <title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title> |
---|
3934 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke"> |
---|
3935 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3936 | <address> |
---|
3937 | <postal> |
---|
3938 | <street>Hafenweg 16</street> |
---|
3939 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
3940 | <country>Germany</country> |
---|
3941 | </postal> |
---|
3942 | <email>julian.reschke@greenbytes.de</email> |
---|
3943 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
3944 | </address> |
---|
3945 | </author> |
---|
3946 | <date month="August" year="2010"/> |
---|
3947 | </front> |
---|
3948 | <seriesInfo name="RFC" value="5987"/> |
---|
3949 | </reference> |
---|
3950 | |
---|
3951 | <reference anchor="RFC6151"> |
---|
3952 | <front> |
---|
3953 | <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title> |
---|
3954 | <author initials="S." surname="Turner" fullname="S. Turner"/> |
---|
3955 | <author initials="L." surname="Chen" fullname="L. Chen"/> |
---|
3956 | <date year="2011" month="March" /> |
---|
3957 | </front> |
---|
3958 | <seriesInfo name="RFC" value="6151" /> |
---|
3959 | </reference> |
---|
3960 | |
---|
3961 | <reference anchor="RFC6266"> |
---|
3962 | <front> |
---|
3963 | <title abbrev="Content-Disposition in HTTP">Use of the Content-Disposition Header Field |
---|
3964 | in the Hypertext Transfer Protocol (HTTP)</title> |
---|
3965 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke"> |
---|
3966 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3967 | <address> |
---|
3968 | <email>julian.reschke@greenbytes.de</email> |
---|
3969 | </address> |
---|
3970 | </author> |
---|
3971 | <date month="June" year="2011"/> |
---|
3972 | </front> |
---|
3973 | <seriesInfo name='RFC' value='6266' /> |
---|
3974 | </reference> |
---|
3975 | |
---|
3976 | <reference anchor="draft-reschke-http-status-308"> |
---|
3977 | <front> |
---|
3978 | <title abbrev="HTTP Status Code 308">The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)</title> |
---|
3979 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke"> |
---|
3980 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3981 | <address> |
---|
3982 | <email>julian.reschke@greenbytes.de</email> |
---|
3983 | </address> |
---|
3984 | </author> |
---|
3985 | <date month="March" year="2012"/> |
---|
3986 | </front> |
---|
3987 | <seriesInfo name="Internet-Draft" value="draft-reschke-http-status-308-07"/> |
---|
3988 | </reference> |
---|
3989 | |
---|
3990 | </references> |
---|
3991 | |
---|
3992 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
3993 | <t> |
---|
3994 | Clarify definition of POST. |
---|
3995 | (<xref target="POST"/>) |
---|
3996 | </t> |
---|
3997 | <t> |
---|
3998 | Remove requirement to handle all Content-* header fields; ban use of |
---|
3999 | Content-Range with PUT. |
---|
4000 | (<xref target="PUT"/>) |
---|
4001 | </t> |
---|
4002 | <t> |
---|
4003 | Take over definition of CONNECT method from <xref target="RFC2817"/>. |
---|
4004 | (<xref target="CONNECT"/>) |
---|
4005 | </t> |
---|
4006 | <t> |
---|
4007 | This document takes over the Status Code Registry, previously defined |
---|
4008 | in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. |
---|
4009 | (<xref target="status.code.registry"/>) |
---|
4010 | </t> |
---|
4011 | <t> |
---|
4012 | Broadened the definition of 203 (Non-Authoritative Information) to include |
---|
4013 | cases of payload transformations as well. |
---|
4014 | (<xref target="status.203"/>) |
---|
4015 | </t> |
---|
4016 | <t> |
---|
4017 | Status codes 301, 302, and 307: removed the normative requirements on both |
---|
4018 | response payloads and user interaction. |
---|
4019 | (<xref target="status.3xx"/>) |
---|
4020 | </t> |
---|
4021 | <t> |
---|
4022 | Failed to consider that there are many other request methods that are safe |
---|
4023 | to automatically redirect, and further that the user agent is able to make |
---|
4024 | that determination based on the request method semantics. |
---|
4025 | Furthermore, allow user agents to rewrite the method from POST to GET |
---|
4026 | for status codes 301 and 302. |
---|
4027 | (Sections <xref format="counter" target="status.301"/>, |
---|
4028 | <xref format="counter" target="status.302"/> and |
---|
4029 | <xref format="counter" target="status.307"/>) |
---|
4030 | </t> |
---|
4031 | <t> |
---|
4032 | Deprecate 305 Use Proxy status code, because user agents did not implement it. |
---|
4033 | It used to indicate that the target resource needs to be accessed through the |
---|
4034 | proxy given by the Location field. The Location field gave the URI of the |
---|
4035 | proxy. The recipient was expected to repeat this single request via the proxy. |
---|
4036 | (<xref target="status.305"/>) |
---|
4037 | </t> |
---|
4038 | <t> |
---|
4039 | Define status 426 (Upgrade Required) (this was incorporated from |
---|
4040 | <xref target="RFC2817"/>). |
---|
4041 | (<xref target="status.426"/>) |
---|
4042 | </t> |
---|
4043 | <t> |
---|
4044 | Change ABNF productions for header fields to only define the field value. |
---|
4045 | (<xref target="header.field.definitions"/>) |
---|
4046 | </t> |
---|
4047 | <t> |
---|
4048 | Reclassify "Allow" as response header field, removing the option to |
---|
4049 | specify it in a PUT request. |
---|
4050 | Relax the server requirement on the contents of the Allow header field and |
---|
4051 | remove requirement on clients to always trust the header field value. |
---|
4052 | (<xref target="header.allow"/>) |
---|
4053 | </t> |
---|
4054 | <t> |
---|
4055 | The ABNF for the Expect header field has been both fixed (allowing parameters |
---|
4056 | for value-less expectations as well) and simplified (allowing trailing |
---|
4057 | semicolons after "100-continue" when they were invalid before). |
---|
4058 | (<xref target="header.expect"/>) |
---|
4059 | </t> |
---|
4060 | <t> |
---|
4061 | Correct syntax of Location header field to allow URI references (including |
---|
4062 | relative references and fragments), as referred symbol "absoluteURI" wasn't |
---|
4063 | what was expected, and add some clarifications as to when use of fragments |
---|
4064 | would not be appropriate. |
---|
4065 | (<xref target="header.location"/>) |
---|
4066 | </t> |
---|
4067 | <t> |
---|
4068 | Restrict Max-Forwards header field to OPTIONS and TRACE (previously, |
---|
4069 | extension methods could have used it as well). |
---|
4070 | (<xref target="header.max-forwards"/>) |
---|
4071 | </t> |
---|
4072 | <t> |
---|
4073 | Allow Referer field value of "about:blank" as alternative to not specifying it. |
---|
4074 | (<xref target="header.referer"/>) |
---|
4075 | </t> |
---|
4076 | <t> |
---|
4077 | In the description of the Server header field, the Via field |
---|
4078 | was described as a SHOULD. The requirement was and is stated |
---|
4079 | correctly in the description of the Via header field in &header-via;. |
---|
4080 | (<xref target="header.server"/>) |
---|
4081 | </t> |
---|
4082 | </section> |
---|
4083 | |
---|
4084 | <?BEGININC p2-semantics.abnf-appendix ?> |
---|
4085 | <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf"> |
---|
4086 | <figure> |
---|
4087 | <artwork type="abnf" name="p2-semantics.parsed-abnf"> |
---|
4088 | <x:ref>Allow</x:ref> = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] |
---|
4089 | |
---|
4090 | <x:ref>BWS</x:ref> = <BWS, defined in [Part1], Section 3.2.1> |
---|
4091 | |
---|
4092 | <x:ref>Date</x:ref> = HTTP-date |
---|
4093 | |
---|
4094 | <x:ref>Expect</x:ref> = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
---|
4095 | |
---|
4096 | <x:ref>From</x:ref> = mailbox |
---|
4097 | |
---|
4098 | <x:ref>GMT</x:ref> = %x47.4D.54 ; GMT |
---|
4099 | |
---|
4100 | <x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date |
---|
4101 | |
---|
4102 | <x:ref>Location</x:ref> = URI-reference |
---|
4103 | |
---|
4104 | <x:ref>Max-Forwards</x:ref> = 1*DIGIT |
---|
4105 | |
---|
4106 | <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 3.2.1> |
---|
4107 | |
---|
4108 | <x:ref>RWS</x:ref> = <RWS, defined in [Part1], Section 3.2.1> |
---|
4109 | <x:ref>Referer</x:ref> = absolute-URI / partial-URI |
---|
4110 | <x:ref>Retry-After</x:ref> = HTTP-date / delta-seconds |
---|
4111 | |
---|
4112 | <x:ref>Server</x:ref> = product *( RWS ( product / comment ) ) |
---|
4113 | |
---|
4114 | <x:ref>URI-reference</x:ref> = <URI-reference, defined in [Part1], Section 2.7> |
---|
4115 | <x:ref>User-Agent</x:ref> = product *( RWS ( product / comment ) ) |
---|
4116 | |
---|
4117 | <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [Part1], Section 2.7> |
---|
4118 | <x:ref>asctime-date</x:ref> = day-name SP date3 SP time-of-day SP year |
---|
4119 | |
---|
4120 | <x:ref>comment</x:ref> = <comment, defined in [Part1], Section 3.2.4> |
---|
4121 | |
---|
4122 | <x:ref>date1</x:ref> = day SP month SP year |
---|
4123 | <x:ref>date2</x:ref> = day "-" month "-" 2DIGIT |
---|
4124 | <x:ref>date3</x:ref> = month SP ( 2DIGIT / ( SP DIGIT ) ) |
---|
4125 | <x:ref>day</x:ref> = 2DIGIT |
---|
4126 | <x:ref>day-name</x:ref> = %x4D.6F.6E ; Mon |
---|
4127 | / %x54.75.65 ; Tue |
---|
4128 | / %x57.65.64 ; Wed |
---|
4129 | / %x54.68.75 ; Thu |
---|
4130 | / %x46.72.69 ; Fri |
---|
4131 | / %x53.61.74 ; Sat |
---|
4132 | / %x53.75.6E ; Sun |
---|
4133 | <x:ref>day-name-l</x:ref> = %x4D.6F.6E.64.61.79 ; Monday |
---|
4134 | / %x54.75.65.73.64.61.79 ; Tuesday |
---|
4135 | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
---|
4136 | / %x54.68.75.72.73.64.61.79 ; Thursday |
---|
4137 | / %x46.72.69.64.61.79 ; Friday |
---|
4138 | / %x53.61.74.75.72.64.61.79 ; Saturday |
---|
4139 | / %x53.75.6E.64.61.79 ; Sunday |
---|
4140 | <x:ref>delta-seconds</x:ref> = 1*DIGIT |
---|
4141 | |
---|
4142 | <x:ref>expect-name</x:ref> = token |
---|
4143 | <x:ref>expect-param</x:ref> = expect-name [ BWS "=" BWS expect-value ] |
---|
4144 | <x:ref>expect-value</x:ref> = token / quoted-string |
---|
4145 | <x:ref>expectation</x:ref> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ |
---|
4146 | OWS expect-param ] ) |
---|
4147 | |
---|
4148 | <x:ref>hour</x:ref> = 2DIGIT |
---|
4149 | |
---|
4150 | <x:ref>mailbox</x:ref> = <mailbox, defined in [RFC5322], Section 3.4> |
---|
4151 | <x:ref>method</x:ref> = token |
---|
4152 | <x:ref>minute</x:ref> = 2DIGIT |
---|
4153 | <x:ref>month</x:ref> = %x4A.61.6E ; Jan |
---|
4154 | / %x46.65.62 ; Feb |
---|
4155 | / %x4D.61.72 ; Mar |
---|
4156 | / %x41.70.72 ; Apr |
---|
4157 | / %x4D.61.79 ; May |
---|
4158 | / %x4A.75.6E ; Jun |
---|
4159 | / %x4A.75.6C ; Jul |
---|
4160 | / %x41.75.67 ; Aug |
---|
4161 | / %x53.65.70 ; Sep |
---|
4162 | / %x4F.63.74 ; Oct |
---|
4163 | / %x4E.6F.76 ; Nov |
---|
4164 | / %x44.65.63 ; Dec |
---|
4165 | |
---|
4166 | <x:ref>obs-date</x:ref> = rfc850-date / asctime-date |
---|
4167 | <x:ref>obs-text</x:ref> = <obs-text, defined in [Part1], Section 3.2.4> |
---|
4168 | |
---|
4169 | <x:ref>partial-URI</x:ref> = <partial-URI, defined in [Part1], Section 2.7> |
---|
4170 | <x:ref>product</x:ref> = token [ "/" product-version ] |
---|
4171 | <x:ref>product-version</x:ref> = token |
---|
4172 | |
---|
4173 | <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 3.2.4> |
---|
4174 | |
---|
4175 | <x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT |
---|
4176 | <x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT |
---|
4177 | |
---|
4178 | <x:ref>second</x:ref> = 2DIGIT |
---|
4179 | |
---|
4180 | <x:ref>time-of-day</x:ref> = hour ":" minute ":" second |
---|
4181 | <x:ref>token</x:ref> = <token, defined in [Part1], Section 3.2.4> |
---|
4182 | |
---|
4183 | word = <word, defined in [Part1], Section 3.2.4> |
---|
4184 | |
---|
4185 | <x:ref>year</x:ref> = 4DIGIT |
---|
4186 | </artwork> |
---|
4187 | </figure> |
---|
4188 | <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> |
---|
4189 | ; Allow defined but not used |
---|
4190 | ; Date defined but not used |
---|
4191 | ; Expect defined but not used |
---|
4192 | ; From defined but not used |
---|
4193 | ; Location defined but not used |
---|
4194 | ; Max-Forwards defined but not used |
---|
4195 | ; Referer defined but not used |
---|
4196 | ; Retry-After defined but not used |
---|
4197 | ; Server defined but not used |
---|
4198 | ; User-Agent defined but not used |
---|
4199 | ; obs-text defined but not used |
---|
4200 | ; word defined but not used |
---|
4201 | </artwork></figure></section> |
---|
4202 | <?ENDINC p2-semantics.abnf-appendix ?> |
---|
4203 | |
---|
4204 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
4205 | |
---|
4206 | <section title="Since RFC 2616"> |
---|
4207 | <t> |
---|
4208 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
4209 | </t> |
---|
4210 | </section> |
---|
4211 | |
---|
4212 | <section title="Since draft-ietf-httpbis-p2-semantics-00"> |
---|
4213 | <t> |
---|
4214 | Closed issues: |
---|
4215 | <list style="symbols"> |
---|
4216 | <t> |
---|
4217 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/5"/>: |
---|
4218 | "Via is a MUST" |
---|
4219 | (<eref target="http://purl.org/NET/http-errata#via-must"/>) |
---|
4220 | </t> |
---|
4221 | <t> |
---|
4222 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/6"/>: |
---|
4223 | "Fragments allowed in Location" |
---|
4224 | (<eref target="http://purl.org/NET/http-errata#location-fragments"/>) |
---|
4225 | </t> |
---|
4226 | <t> |
---|
4227 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/10"/>: |
---|
4228 | "Safe Methods vs Redirection" |
---|
4229 | (<eref target="http://purl.org/NET/http-errata#saferedirect"/>) |
---|
4230 | </t> |
---|
4231 | <t> |
---|
4232 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/17"/>: |
---|
4233 | "Revise description of the POST method" |
---|
4234 | (<eref target="http://purl.org/NET/http-errata#post"/>) |
---|
4235 | </t> |
---|
4236 | <t> |
---|
4237 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
4238 | "Normative and Informative references" |
---|
4239 | </t> |
---|
4240 | <t> |
---|
4241 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/42"/>: |
---|
4242 | "RFC2606 Compliance" |
---|
4243 | </t> |
---|
4244 | <t> |
---|
4245 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>: |
---|
4246 | "Informative references" |
---|
4247 | </t> |
---|
4248 | <t> |
---|
4249 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/84"/>: |
---|
4250 | "Redundant cross-references" |
---|
4251 | </t> |
---|
4252 | </list> |
---|
4253 | </t> |
---|
4254 | <t> |
---|
4255 | Other changes: |
---|
4256 | <list style="symbols"> |
---|
4257 | <t> |
---|
4258 | Move definitions of 304 and 412 condition codes to <xref target="Part4"/> |
---|
4259 | </t> |
---|
4260 | </list> |
---|
4261 | </t> |
---|
4262 | </section> |
---|
4263 | |
---|
4264 | <section title="Since draft-ietf-httpbis-p2-semantics-01"> |
---|
4265 | <t> |
---|
4266 | Closed issues: |
---|
4267 | <list style="symbols"> |
---|
4268 | <t> |
---|
4269 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/21"/>: |
---|
4270 | "PUT side effects" |
---|
4271 | </t> |
---|
4272 | <t> |
---|
4273 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/91"/>: |
---|
4274 | "Duplicate Host header requirements" |
---|
4275 | </t> |
---|
4276 | </list> |
---|
4277 | </t> |
---|
4278 | <t> |
---|
4279 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4280 | <list style="symbols"> |
---|
4281 | <t> |
---|
4282 | Move "Product Tokens" section (back) into Part 1, as "token" is used |
---|
4283 | in the definition of the Upgrade header field. |
---|
4284 | </t> |
---|
4285 | <t> |
---|
4286 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
4287 | </t> |
---|
4288 | <t> |
---|
4289 | Copy definition of delta-seconds from Part6 instead of referencing it. |
---|
4290 | </t> |
---|
4291 | </list> |
---|
4292 | </t> |
---|
4293 | </section> |
---|
4294 | |
---|
4295 | <section title="Since draft-ietf-httpbis-p2-semantics-02" anchor="changes.since.02"> |
---|
4296 | <t> |
---|
4297 | Closed issues: |
---|
4298 | <list style="symbols"> |
---|
4299 | <t> |
---|
4300 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/24"/>: |
---|
4301 | "Requiring Allow in 405 responses" |
---|
4302 | </t> |
---|
4303 | <t> |
---|
4304 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/59"/>: |
---|
4305 | "Status Code Registry" |
---|
4306 | </t> |
---|
4307 | <t> |
---|
4308 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/61"/>: |
---|
4309 | "Redirection vs. Location" |
---|
4310 | </t> |
---|
4311 | <t> |
---|
4312 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/70"/>: |
---|
4313 | "Cacheability of 303 response" |
---|
4314 | </t> |
---|
4315 | <t> |
---|
4316 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/76"/>: |
---|
4317 | "305 Use Proxy" |
---|
4318 | </t> |
---|
4319 | <t> |
---|
4320 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>: |
---|
4321 | "Classification for Allow header" |
---|
4322 | </t> |
---|
4323 | <t> |
---|
4324 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/112"/>: |
---|
4325 | "PUT - 'store under' vs 'store at'" |
---|
4326 | </t> |
---|
4327 | </list> |
---|
4328 | </t> |
---|
4329 | <t> |
---|
4330 | Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
4331 | <list style="symbols"> |
---|
4332 | <t> |
---|
4333 | Reference RFC 3984, and update header field registrations for headers defined |
---|
4334 | in this document. |
---|
4335 | </t> |
---|
4336 | </list> |
---|
4337 | </t> |
---|
4338 | <t> |
---|
4339 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4340 | <list style="symbols"> |
---|
4341 | <t> |
---|
4342 | Replace string literals when the string really is case-sensitive (method). |
---|
4343 | </t> |
---|
4344 | </list> |
---|
4345 | </t> |
---|
4346 | </section> |
---|
4347 | |
---|
4348 | <section title="Since draft-ietf-httpbis-p2-semantics-03" anchor="changes.since.03"> |
---|
4349 | <t> |
---|
4350 | Closed issues: |
---|
4351 | <list style="symbols"> |
---|
4352 | <t> |
---|
4353 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/98"/>: |
---|
4354 | "OPTIONS request bodies" |
---|
4355 | </t> |
---|
4356 | <t> |
---|
4357 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/119"/>: |
---|
4358 | "Description of CONNECT should refer to RFC2817" |
---|
4359 | </t> |
---|
4360 | <t> |
---|
4361 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/125"/>: |
---|
4362 | "Location Content-Location reference request/response mixup" |
---|
4363 | </t> |
---|
4364 | </list> |
---|
4365 | </t> |
---|
4366 | <t> |
---|
4367 | Ongoing work on Method Registry (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/72"/>): |
---|
4368 | <list style="symbols"> |
---|
4369 | <t> |
---|
4370 | Added initial proposal for registration process, plus initial |
---|
4371 | content (non-HTTP/1.1 methods to be added by a separate specification). |
---|
4372 | </t> |
---|
4373 | </list> |
---|
4374 | </t> |
---|
4375 | </section> |
---|
4376 | |
---|
4377 | <section title="Since draft-ietf-httpbis-p2-semantics-04" anchor="changes.since.04"> |
---|
4378 | <t> |
---|
4379 | Closed issues: |
---|
4380 | <list style="symbols"> |
---|
4381 | <t> |
---|
4382 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/103"/>: |
---|
4383 | "Content-*" |
---|
4384 | </t> |
---|
4385 | <t> |
---|
4386 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>: |
---|
4387 | "RFC 2822 is updated by RFC 5322" |
---|
4388 | </t> |
---|
4389 | </list> |
---|
4390 | </t> |
---|
4391 | <t> |
---|
4392 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4393 | <list style="symbols"> |
---|
4394 | <t> |
---|
4395 | Use "/" instead of "|" for alternatives. |
---|
4396 | </t> |
---|
4397 | <t> |
---|
4398 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
4399 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
4400 | </t> |
---|
4401 | <t> |
---|
4402 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
4403 | header field value format definitions. |
---|
4404 | </t> |
---|
4405 | </list> |
---|
4406 | </t> |
---|
4407 | </section> |
---|
4408 | |
---|
4409 | <section title="Since draft-ietf-httpbis-p2-semantics-05" anchor="changes.since.05"> |
---|
4410 | <t> |
---|
4411 | Closed issues: |
---|
4412 | <list style="symbols"> |
---|
4413 | <t> |
---|
4414 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>: |
---|
4415 | "reason-phrase BNF" |
---|
4416 | </t> |
---|
4417 | </list> |
---|
4418 | </t> |
---|
4419 | <t> |
---|
4420 | Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4421 | <list style="symbols"> |
---|
4422 | <t> |
---|
4423 | Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. |
---|
4424 | </t> |
---|
4425 | </list> |
---|
4426 | </t> |
---|
4427 | </section> |
---|
4428 | |
---|
4429 | <section title="Since draft-ietf-httpbis-p2-semantics-06" anchor="changes.since.06"> |
---|
4430 | <t> |
---|
4431 | Closed issues: |
---|
4432 | <list style="symbols"> |
---|
4433 | <t> |
---|
4434 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/144"/>: |
---|
4435 | "Clarify when Referer is sent" |
---|
4436 | </t> |
---|
4437 | <t> |
---|
4438 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/164"/>: |
---|
4439 | "status codes vs methods" |
---|
4440 | </t> |
---|
4441 | <t> |
---|
4442 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/170"/>: |
---|
4443 | "Do not require "updates" relation for specs that register status codes or method names" |
---|
4444 | </t> |
---|
4445 | </list> |
---|
4446 | </t> |
---|
4447 | </section> |
---|
4448 | |
---|
4449 | <section title="Since draft-ietf-httpbis-p2-semantics-07" anchor="changes.since.07"> |
---|
4450 | <t> |
---|
4451 | Closed issues: |
---|
4452 | <list style="symbols"> |
---|
4453 | <t> |
---|
4454 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/27"/>: |
---|
4455 | "Idempotency" |
---|
4456 | </t> |
---|
4457 | <t> |
---|
4458 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/33"/>: |
---|
4459 | "TRACE security considerations" |
---|
4460 | </t> |
---|
4461 | <t> |
---|
4462 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>: |
---|
4463 | "Clarify rules for determining what entities a response carries" |
---|
4464 | </t> |
---|
4465 | <t> |
---|
4466 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/140"/>: |
---|
4467 | "update note citing RFC 1945 and 2068" |
---|
4468 | </t> |
---|
4469 | <t> |
---|
4470 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/182"/>: |
---|
4471 | "update note about redirect limit" |
---|
4472 | </t> |
---|
4473 | <t> |
---|
4474 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/191"/>: |
---|
4475 | "Location header ABNF should use 'URI'" |
---|
4476 | </t> |
---|
4477 | <t> |
---|
4478 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/192"/>: |
---|
4479 | "fragments in Location vs status 303" |
---|
4480 | </t> |
---|
4481 | <t> |
---|
4482 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>: |
---|
4483 | "move IANA registrations for optional status codes" |
---|
4484 | </t> |
---|
4485 | </list> |
---|
4486 | </t> |
---|
4487 | <t> |
---|
4488 | Partly resolved issues: |
---|
4489 | <list style="symbols"> |
---|
4490 | <t> |
---|
4491 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/171"/>: |
---|
4492 | "Are OPTIONS and TRACE safe?" |
---|
4493 | </t> |
---|
4494 | </list> |
---|
4495 | </t> |
---|
4496 | </section> |
---|
4497 | |
---|
4498 | <section title="Since draft-ietf-httpbis-p2-semantics-08" anchor="changes.since.08"> |
---|
4499 | <t> |
---|
4500 | Closed issues: |
---|
4501 | <list style="symbols"> |
---|
4502 | <t> |
---|
4503 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/10"/>: |
---|
4504 | "Safe Methods vs Redirection" (we missed the introduction to the 3xx |
---|
4505 | status codes when fixing this previously) |
---|
4506 | </t> |
---|
4507 | </list> |
---|
4508 | </t> |
---|
4509 | </section> |
---|
4510 | |
---|
4511 | <section title="Since draft-ietf-httpbis-p2-semantics-09" anchor="changes.since.09"> |
---|
4512 | <t> |
---|
4513 | Closed issues: |
---|
4514 | <list style="symbols"> |
---|
4515 | <t> |
---|
4516 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/43"/>: |
---|
4517 | "Fragment combination / precedence during redirects" |
---|
4518 | </t> |
---|
4519 | </list> |
---|
4520 | </t> |
---|
4521 | <t> |
---|
4522 | Partly resolved issues: |
---|
4523 | <list style="symbols"> |
---|
4524 | <t> |
---|
4525 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>: |
---|
4526 | "Location header payload handling" |
---|
4527 | </t> |
---|
4528 | <t> |
---|
4529 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: |
---|
4530 | "Term for the requested resource's URI" |
---|
4531 | </t> |
---|
4532 | </list> |
---|
4533 | </t> |
---|
4534 | </section> |
---|
4535 | |
---|
4536 | <section title="Since draft-ietf-httpbis-p2-semantics-10" anchor="changes.since.10"> |
---|
4537 | <t> |
---|
4538 | Closed issues: |
---|
4539 | <list style="symbols"> |
---|
4540 | <t> |
---|
4541 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/69"/>: |
---|
4542 | "Clarify 'Requested Variant'" |
---|
4543 | </t> |
---|
4544 | <t> |
---|
4545 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>: |
---|
4546 | "Clarify entity / representation / variant terminology" |
---|
4547 | </t> |
---|
4548 | <t> |
---|
4549 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/139"/>: |
---|
4550 | "Methods and Caching" |
---|
4551 | </t> |
---|
4552 | <t> |
---|
4553 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/190"/>: |
---|
4554 | "OPTIONS vs Max-Forwards" |
---|
4555 | </t> |
---|
4556 | <t> |
---|
4557 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/199"/>: |
---|
4558 | "Status codes and caching" |
---|
4559 | </t> |
---|
4560 | <t> |
---|
4561 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: |
---|
4562 | "consider removing the 'changes from 2068' sections" |
---|
4563 | </t> |
---|
4564 | </list> |
---|
4565 | </t> |
---|
4566 | </section> |
---|
4567 | |
---|
4568 | <section title="Since draft-ietf-httpbis-p2-semantics-11" anchor="changes.since.11"> |
---|
4569 | <t> |
---|
4570 | Closed issues: |
---|
4571 | <list style="symbols"> |
---|
4572 | <t> |
---|
4573 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/229"/>: |
---|
4574 | "Considerations for new status codes" |
---|
4575 | </t> |
---|
4576 | <t> |
---|
4577 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/230"/>: |
---|
4578 | "Considerations for new methods" |
---|
4579 | </t> |
---|
4580 | <t> |
---|
4581 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/232"/>: |
---|
4582 | "User-Agent guidelines" (relating to the 'User-Agent' header field) |
---|
4583 | </t> |
---|
4584 | </list> |
---|
4585 | </t> |
---|
4586 | </section> |
---|
4587 | |
---|
4588 | <section title="Since draft-ietf-httpbis-p2-semantics-12" anchor="changes.since.12"> |
---|
4589 | <t> |
---|
4590 | Closed issues: |
---|
4591 | <list style="symbols"> |
---|
4592 | <t> |
---|
4593 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/43"/>: |
---|
4594 | "Fragment combination / precedence during redirects" (added warning |
---|
4595 | about having a fragid on the redirect may cause inconvenience in |
---|
4596 | some cases) |
---|
4597 | </t> |
---|
4598 | <t> |
---|
4599 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/79"/>: |
---|
4600 | "Content-* vs. PUT" |
---|
4601 | </t> |
---|
4602 | <t> |
---|
4603 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>: |
---|
4604 | "205 Bodies" |
---|
4605 | </t> |
---|
4606 | <t> |
---|
4607 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/102"/>: |
---|
4608 | "Understanding Content-* on non-PUT requests" |
---|
4609 | </t> |
---|
4610 | <t> |
---|
4611 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/103"/>: |
---|
4612 | "Content-*" |
---|
4613 | </t> |
---|
4614 | <t> |
---|
4615 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/104"/>: |
---|
4616 | "Header type defaulting" |
---|
4617 | </t> |
---|
4618 | <t> |
---|
4619 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/112"/>: |
---|
4620 | "PUT - 'store under' vs 'store at'" |
---|
4621 | </t> |
---|
4622 | <t> |
---|
4623 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/137"/>: |
---|
4624 | "duplicate ABNF for reason-phrase" |
---|
4625 | </t> |
---|
4626 | <t> |
---|
4627 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/180"/>: |
---|
4628 | "Note special status of Content-* prefix in header registration procedures" |
---|
4629 | </t> |
---|
4630 | <t> |
---|
4631 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/203"/>: |
---|
4632 | "Max-Forwards vs extension methods" |
---|
4633 | </t> |
---|
4634 | <t> |
---|
4635 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/213"/>: |
---|
4636 | "What is the value space of HTTP status codes?" (actually fixed in |
---|
4637 | draft-ietf-httpbis-p2-semantics-11) |
---|
4638 | </t> |
---|
4639 | <t> |
---|
4640 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>: |
---|
4641 | "Header Classification" |
---|
4642 | </t> |
---|
4643 | <t> |
---|
4644 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/225"/>: |
---|
4645 | "PUT side effect: invalidation or just stale?" |
---|
4646 | </t> |
---|
4647 | <t> |
---|
4648 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/226"/>: |
---|
4649 | "proxies not supporting certain methods" |
---|
4650 | </t> |
---|
4651 | <t> |
---|
4652 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/239"/>: |
---|
4653 | "Migrate CONNECT from RFC2817 to p2" |
---|
4654 | </t> |
---|
4655 | <t> |
---|
4656 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/240"/>: |
---|
4657 | "Migrate Upgrade details from RFC2817" |
---|
4658 | </t> |
---|
4659 | <t> |
---|
4660 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/267"/>: |
---|
4661 | "clarify PUT semantics'" |
---|
4662 | </t> |
---|
4663 | <t> |
---|
4664 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/275"/>: |
---|
4665 | "duplicate ABNF for 'Method'" |
---|
4666 | </t> |
---|
4667 | <t> |
---|
4668 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>: |
---|
4669 | "untangle ABNFs for header fields" |
---|
4670 | </t> |
---|
4671 | </list> |
---|
4672 | </t> |
---|
4673 | </section> |
---|
4674 | |
---|
4675 | <section title="Since draft-ietf-httpbis-p2-semantics-13" anchor="changes.since.13"> |
---|
4676 | <t> |
---|
4677 | Closed issues: |
---|
4678 | <list style="symbols"> |
---|
4679 | <t> |
---|
4680 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>: |
---|
4681 | "untangle ABNFs for header fields" |
---|
4682 | </t> |
---|
4683 | <t> |
---|
4684 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/251"/>: |
---|
4685 | "message body in CONNECT request" |
---|
4686 | </t> |
---|
4687 | </list> |
---|
4688 | </t> |
---|
4689 | </section> |
---|
4690 | |
---|
4691 | <section title="Since draft-ietf-httpbis-p2-semantics-14" anchor="changes.since.14"> |
---|
4692 | <t> |
---|
4693 | Closed issues: |
---|
4694 | <list style="symbols"> |
---|
4695 | <t> |
---|
4696 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>: |
---|
4697 | "Clarify status code for rate limiting" |
---|
4698 | </t> |
---|
4699 | <t> |
---|
4700 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/294"/>: |
---|
4701 | "clarify 403 forbidden" |
---|
4702 | </t> |
---|
4703 | <t> |
---|
4704 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/296"/>: |
---|
4705 | "Clarify 203 Non-Authoritative Information" |
---|
4706 | </t> |
---|
4707 | <t> |
---|
4708 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/298"/>: |
---|
4709 | "update default reason phrase for 413" |
---|
4710 | </t> |
---|
4711 | </list> |
---|
4712 | </t> |
---|
4713 | </section> |
---|
4714 | |
---|
4715 | <section title="Since draft-ietf-httpbis-p2-semantics-15" anchor="changes.since.15"> |
---|
4716 | <t> |
---|
4717 | Closed issues: |
---|
4718 | <list style="symbols"> |
---|
4719 | <t> |
---|
4720 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>: |
---|
4721 | "Strength of requirements on Accept re: 406" |
---|
4722 | </t> |
---|
4723 | <t> |
---|
4724 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/303"/>: |
---|
4725 | "400 response isn't generic" |
---|
4726 | </t> |
---|
4727 | </list> |
---|
4728 | </t> |
---|
4729 | </section> |
---|
4730 | |
---|
4731 | <section title="Since draft-ietf-httpbis-p2-semantics-16" anchor="changes.since.16"> |
---|
4732 | <t> |
---|
4733 | Closed issues: |
---|
4734 | <list style="symbols"> |
---|
4735 | <t> |
---|
4736 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/160"/>: |
---|
4737 | "Redirects and non-GET methods" |
---|
4738 | </t> |
---|
4739 | <t> |
---|
4740 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: |
---|
4741 | "Document HTTP's error-handling philosophy" |
---|
4742 | </t> |
---|
4743 | <t> |
---|
4744 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/231"/>: |
---|
4745 | "Considerations for new headers" |
---|
4746 | </t> |
---|
4747 | <t> |
---|
4748 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/310"/>: |
---|
4749 | "clarify 303 redirect on HEAD" |
---|
4750 | </t> |
---|
4751 | </list> |
---|
4752 | </t> |
---|
4753 | </section> |
---|
4754 | |
---|
4755 | <section title="Since draft-ietf-httpbis-p2-semantics-17" anchor="changes.since.17"> |
---|
4756 | <t> |
---|
4757 | Closed issues: |
---|
4758 | <list style="symbols"> |
---|
4759 | <t> |
---|
4760 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>: |
---|
4761 | "Location header payload handling" |
---|
4762 | </t> |
---|
4763 | <t> |
---|
4764 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>: |
---|
4765 | "Clarify status code for rate limiting" (change backed out because |
---|
4766 | a new status code is being defined for this purpose) |
---|
4767 | </t> |
---|
4768 | <t> |
---|
4769 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/312"/>: |
---|
4770 | "should there be a permanent variant of 307" |
---|
4771 | </t> |
---|
4772 | <t> |
---|
4773 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/325"/>: |
---|
4774 | "When are Location's semantics triggered?" |
---|
4775 | </t> |
---|
4776 | <t> |
---|
4777 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/327"/>: |
---|
4778 | "'expect' grammar missing OWS" |
---|
4779 | </t> |
---|
4780 | <t> |
---|
4781 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/329"/>: |
---|
4782 | "header field considerations: quoted-string vs use of double quotes" |
---|
4783 | </t> |
---|
4784 | </list> |
---|
4785 | </t> |
---|
4786 | </section> |
---|
4787 | |
---|
4788 | <section title="Since draft-ietf-httpbis-p2-semantics-18" anchor="changes.since.18"> |
---|
4789 | <t> |
---|
4790 | Closed issues: |
---|
4791 | <list style="symbols"> |
---|
4792 | <t> |
---|
4793 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/227"/>: |
---|
4794 | "Combining HEAD responses" |
---|
4795 | </t> |
---|
4796 | <t> |
---|
4797 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/238"/>: |
---|
4798 | "Requirements for user intervention during redirects" |
---|
4799 | </t> |
---|
4800 | <t> |
---|
4801 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/250"/>: |
---|
4802 | "message-body in CONNECT response" |
---|
4803 | </t> |
---|
4804 | <t> |
---|
4805 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/295"/>: |
---|
4806 | "Applying original fragment to 'plain' redirected URI" |
---|
4807 | </t> |
---|
4808 | <t> |
---|
4809 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/302"/>: |
---|
4810 | "Misplaced text on connection handling in p2" |
---|
4811 | </t> |
---|
4812 | <t> |
---|
4813 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/331"/>: |
---|
4814 | "clarify that 201 doesn't require Location header fields" |
---|
4815 | </t> |
---|
4816 | <t> |
---|
4817 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/332"/>: |
---|
4818 | "relax requirements on hypertext in 3/4/5xx error responses" |
---|
4819 | </t> |
---|
4820 | <t> |
---|
4821 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/333"/>: |
---|
4822 | "example for 426 response should have a payload" |
---|
4823 | </t> |
---|
4824 | <t> |
---|
4825 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/336"/>: |
---|
4826 | "drop indirection entries for status codes" |
---|
4827 | </t> |
---|
4828 | </list> |
---|
4829 | </t> |
---|
4830 | </section> |
---|
4831 | |
---|
4832 | <section title="Since draft-ietf-httpbis-p2-semantics-19" anchor="changes.since.19"> |
---|
4833 | <t> |
---|
4834 | Closed issues: |
---|
4835 | <list style="symbols"> |
---|
4836 | <t> |
---|
4837 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/312"/>: |
---|
4838 | "should there be a permanent variant of 307" |
---|
4839 | </t> |
---|
4840 | </list> |
---|
4841 | </t> |
---|
4842 | </section> |
---|
4843 | |
---|
4844 | </section> |
---|
4845 | |
---|
4846 | </back> |
---|
4847 | </rfc> |
---|