Ignore:
Timestamp:
Mar 24, 2009, 1:48:26 PM (11 years ago)
Author:
julian.reschke@…
Message:

replace <list> elements used for indentation by <x:note> elements

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r560 r563  
    2929cite {
    3030  font-style: normal;
     31}
     32div.note {
     33  margin-left: 2em;
    3134}
    3235dd {
    … …  
    468471         <tr>
    469472            <td class="header left"></td>
    470             <td class="header right">March 12, 2009</td>
     473            <td class="header right">March 24, 2009</td>
    471474         </tr>
    472475      </table>
    … …  
    11661169      <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.
    11671170         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       <dl class="empty">
    1171          <dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that
     1171         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
    11721175            there might be clients that implement such a fixed limitation.
    1173          </dd>
    1174       </dl>
     1176         </p>
     1177      </div>
    11751178      <div id="rfc.iref.34"></div>
    11761179      <div id="rfc.iref.s.11"></div>
    … …  
    11951198      </p>
    11961199      <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&nbsp;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       <dl 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 erroneously
     1200         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
    12011204            change it into a GET request.
    1202          </dd>
    1203       </dl>
     1205         </p>
     1206      </div>
    12041207      <div id="rfc.iref.36"></div>
    12051208      <div id="rfc.iref.s.13"></div>
    … …  
    12121215      </p>
    12131216      <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&nbsp;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       <dl 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 implementations
     1217         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
    12181221            treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method.
    12191222            The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected
    12201223            of the client.
    1221          </dd>
    1222       </dl>
     1224         </p>
     1225      </div>
    12231226      <div id="rfc.iref.37"></div>
    12241227      <div id="rfc.iref.s.14"></div>
    … …  
    13211324      <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
    13221325         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       <dl 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.
    13271330            In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of
    13281331            an incoming response to determine if it is acceptable.
    1329          </dd>
    1330       </dl>
    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.
    13321335      </p>
    13331336      <div id="rfc.iref.49"></div>
    … …  
    14381441      <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
    14391442      <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       <dl 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 wish
     1443         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
    14441447            to simply refuse the connection.
    1445          </dd>
    1446       </dl>
     1448         </p>
     1449      </div>
    14471450      <div id="rfc.iref.64"></div>
    14481451      <div id="rfc.iref.s.41"></div>
    14491452      <h3 id="rfc.section.8.5.5"><a href="#rfc.section.8.5.5">8.5.5</a>&nbsp;<a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>
    14501453      <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       <dl 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       </dl>
     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>
    14571460      <div id="rfc.iref.65"></div>
    14581461      <div id="rfc.iref.s.42"></div>
    … …  
    15421545</pre><p id="rfc.section.9.4.p.3">An example is:</p>
    15431546      <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.
    15471549            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    1548          </dd>
    1549       </dl>
     1550         </p>
     1551      </div>
    15501552      <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>
    15511553      <ul>
    … …  
    16141616</pre><p id="rfc.section.9.8.p.3">Example:</p>
    16151617      <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       <dl 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 attacks
     1618</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
    16201622            against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable
    16211623            option.
    1622          </dd>
    1623       </dl>
     1624         </p>
     1625      </div>
    16241626      <div id="rfc.iref.u.1"></div>
    16251627      <div id="rfc.iref.h.10"></div>
Note: See TracChangeset for help on using the changeset viewer.