Changeset 563 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- Mar 24, 2009, 1:48:26 PM (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r560 r563 29 29 cite { 30 30 font-style: normal; 31 } 32 div.note { 33 margin-left: 2em; 31 34 } 32 35 dd { … … 468 471 <tr> 469 472 <td class="header left"></td> 470 <td class="header right">March 12, 2009</td>473 <td class="header right">March 24, 2009</td> 471 474 </tr> 472 475 </table> … … 1166 1169 <p id="rfc.section.8.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. 1167 1170 The action required <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is 1168 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 1169 </p> 1170 <d l class="empty">1171 < dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that1171 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 1172 </p> 1173 <div class="note"> 1174 <p> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that 1172 1175 there might be clients that implement such a fixed limitation. 1173 </ dd>1174 </d l>1176 </p> 1177 </div> 1175 1178 <div id="rfc.iref.34"></div> 1176 1179 <div id="rfc.iref.s.11"></div> … … 1195 1198 </p> 1196 1199 <p id="rfc.section.8.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1197 the request was issued. 1198 </p> 1199 <d l class="empty">1200 < dd> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously1200 the request was issued. 1201 </p> 1202 <div class="note"> 1203 <p> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously 1201 1204 change it into a GET request. 1202 </ dd>1203 </d l>1205 </p> 1206 </div> 1204 1207 <div id="rfc.iref.36"></div> 1205 1208 <div id="rfc.iref.s.13"></div> … … 1212 1215 </p> 1213 1216 <p id="rfc.section.8.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1214 the request was issued. 1215 </p> 1216 <d l class="empty">1217 < dd> <b>Note:</b> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations1217 the request was issued. 1218 </p> 1219 <div class="note"> 1220 <p> <b>Note:</b> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations 1218 1221 treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. 1219 1222 The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected 1220 1223 of the client. 1221 </ dd>1222 </d l>1224 </p> 1225 </div> 1223 1226 <div id="rfc.iref.37"></div> 1224 1227 <div id="rfc.iref.s.14"></div> … … 1321 1324 <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent 1322 1325 can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. 1323 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1324 </p> 1325 <d l class="empty">1326 < dd> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.1326 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1327 </p> 1328 <div class="note"> 1329 <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. 1327 1330 In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of 1328 1331 an incoming response to determine if it is acceptable. 1329 </ dd>1330 </d l>1331 <p id="rfc.section.8.4.7.p. 3">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions.1332 </p> 1333 </div> 1334 <p id="rfc.section.8.4.7.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 1332 1335 </p> 1333 1336 <div id="rfc.iref.49"></div> … … 1438 1441 <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> 1439 1442 <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication 1440 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1441 </p> 1442 <d l class="empty">1443 < dd> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish1443 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1444 </p> 1445 <div class="note"> 1446 <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish 1444 1447 to simply refuse the connection. 1445 </ dd>1446 </d l>1448 </p> 1449 </div> 1447 1450 <div id="rfc.iref.64"></div> 1448 1451 <div id="rfc.iref.s.41"></div> 1449 1452 <h3 id="rfc.section.8.5.5"><a href="#rfc.section.8.5.5">8.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3> 1450 1453 <p id="rfc.section.8.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the 1451 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 1452 </p> 1453 <d l class="empty">1454 < dd> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.1455 </ dd>1456 </d l>1454 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 1455 </p> 1456 <div class="note"> 1457 <p> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. 1458 </p> 1459 </div> 1457 1460 <div id="rfc.iref.65"></div> 1458 1461 <div id="rfc.iref.s.42"></div> … … 1542 1545 </pre><p id="rfc.section.9.4.p.3">An example is:</p> 1543 1546 <div id="rfc.figure.u.18"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html 1544 </pre><p id="rfc.section.9.4.p.5"> </p> 1545 <dl class="empty"> 1546 <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response. 1547 </pre><div class="note"> 1548 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response. 1547 1549 It is therefore possible for a response to contain header fields for both Location and Content-Location. 1548 </ dd>1549 </d l>1550 </p> 1551 </div> 1550 1552 <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p> 1551 1553 <ul> … … 1614 1616 </pre><p id="rfc.section.9.8.p.3">Example:</p> 1615 1617 <div id="rfc.figure.u.26"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1616 </pre><p id="rfc.section.9.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1617 </p> 1618 <d l class="empty">1619 < dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks1618 </pre><p id="rfc.section.9.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1619 </p> 1620 <div class="note"> 1621 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 1620 1622 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable 1621 1623 option. 1622 </ dd>1623 </d l>1624 </p> 1625 </div> 1624 1626 <div id="rfc.iref.u.1"></div> 1625 1627 <div id="rfc.iref.h.10"></div>
Note: See TracChangeset
for help on using the changeset viewer.