Ignore:
Timestamp:
Mar 24, 2009, 1:48:26 PM (10 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.xml

    r547 r563  
    12441244   GET or HEAD. A client &SHOULD; detect infinite redirection loops, since
    12451245   such loops generate network traffic for each redirection.
    1246   <list><t>
    1247       <x:h>Note:</x:h> previous versions of this specification recommended a
    1248       maximum of five redirections. Content developers should be aware
    1249       that there might be clients that implement such a fixed
    1250       limitation.
    1251   </t></list>
    1252 </t>
     1246</t>
     1247<x:note>
     1248  <t>
     1249    <x:h>Note:</x:h> previous versions of this specification recommended a
     1250    maximum of five redirections. Content developers should be aware
     1251    that there might be clients that implement such a fixed
     1252    limitation.
     1253  </t>
     1254</x:note>
    12531255
    12541256<section title="300 Multiple Choices" anchor="status.300">
    … …  
    13041306   request unless it can be confirmed by the user, since this might
    13051307   change the conditions under which the request was issued.
    1306   <list><t>
    1307       <x:h>Note:</x:h> When automatically redirecting a POST request after
    1308       receiving a 301 status code, some existing HTTP/1.0 user agents
    1309       will erroneously change it into a GET request.
    1310   </t></list>
    1311 </t>
     1308</t>
     1309<x:note>
     1310  <t>
     1311    <x:h>Note:</x:h> When automatically redirecting a POST request after
     1312    receiving a 301 status code, some existing HTTP/1.0 user agents
     1313    will erroneously change it into a GET request.
     1314  </t>
     1315</x:note>
    13121316</section>
    13131317
    … …  
    13351339   request unless it can be confirmed by the user, since this might
    13361340   change the conditions under which the request was issued.
    1337   <list><t>
    1338       <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed
    1339       to change the method on the redirected request.  However, most
    1340       existing user agent implementations treat 302 as if it were a 303
    1341       response, performing a GET on the Location field-value regardless
    1342       of the original request method. The status codes 303 and 307 have
    1343       been added for servers that wish to make unambiguously clear which
    1344       kind of reaction is expected of the client.
    1345   </t></list>
    1346 </t>
     1341</t>
     1342<x:note>
     1343  <t>
     1344    <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed
     1345    to change the method on the redirected request.  However, most
     1346    existing user agent implementations treat 302 as if it were a 303
     1347    response, performing a GET on the Location field-value regardless
     1348    of the original request method. The status codes 303 and 307 have
     1349    been added for servers that wish to make unambiguously clear which
     1350    kind of reaction is expected of the client.
     1351  </t>
     1352</x:note>
    13471353</section>
    13481354
    … …  
    15461552   choice &MAY; be performed automatically. However, this specification
    15471553   does not define any standard for such automatic selection.
    1548   <list><t>
    1549       <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
    1550       not acceptable according to the accept headers sent in the
    1551       request. In some cases, this may even be preferable to sending a
    1552       406 response. User agents are encouraged to inspect the headers of
    1553       an incoming response to determine if it is acceptable.
    1554   </t></list>
    1555 </t>
     1554</t>
     1555<x:note>
     1556  <t>
     1557    <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
     1558    not acceptable according to the accept headers sent in the
     1559    request. In some cases, this may even be preferable to sending a
     1560    406 response. User agents are encouraged to inspect the headers of
     1561    an incoming response to determine if it is acceptable.
     1562  </t>
     1563</x:note>
    15561564<t>
    15571565   If the response could be unacceptable, a user agent &SHOULD;
    … …  
    17661774   Retry-After header. If no Retry-After is given, the client &SHOULD;
    17671775   handle the response as it would for a 500 response.
    1768   <list><t>
    1769       <x:h>Note:</x:h> The existence of the 503 status code does not imply that a
    1770       server must use it when becoming overloaded. Some servers may wish
    1771       to simply refuse the connection.
    1772   </t></list>
    1773 </t>
     1776</t>
     1777<x:note>
     1778  <t>
     1779    <x:h>Note:</x:h> The existence of the 503 status code does not imply that a
     1780    server must use it when becoming overloaded. Some servers may wish
     1781    to simply refuse the connection.
     1782  </t>
     1783</x:note>
    17741784</section>
    17751785
    … …  
    17821792   HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
    17831793   to access in attempting to complete the request.
    1784   <list><t>
    1785       <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to
    1786       return 400 or 500 when DNS lookups time out.
    1787   </t></list>
    1788 </t>
     1794</t>
     1795<x:note>
     1796  <t>
     1797    <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to
     1798    return 400 or 500 when DNS lookups time out.
     1799  </t>
     1800</x:note>
    17891801</section>
    17901802
    … …  
    19791991  Location: http://www.example.org/pub/WWW/People.html
    19801992</artwork></figure>
    1981 <t>
    1982   <list><t>
    1983       <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs
    1984       from Location in that the Content-Location identifies the original
    1985       location of the entity enclosed in the response. It is therefore
    1986       possible for a response to contain header fields for both Location
    1987       and Content-Location.
    1988   </t></list>
    1989 </t>
     1993<x:note>
     1994  <t>
     1995    <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs
     1996    from Location in that the Content-Location identifies the original
     1997    location of the entity enclosed in the response. It is therefore
     1998    possible for a response to contain header fields for both Location
     1999    and Content-Location.
     2000  </t>
     2001</x:note>
    19902002<t>
    19912003   There are circumstances in which a fragment identifier in a Location URL would not be appropriate:
    … …  
    21342146   application &MUST-NOT; modify the Server response-header. Instead, it
    21352147   &MUST; include a Via field (as described in &header-via;).
    2136   <list><t>
    2137       <x:h>Note:</x:h> Revealing the specific software version of the server might
    2138       allow the server machine to become more vulnerable to attacks
    2139       against software that is known to contain security holes. Server
    2140       implementors are encouraged to make this field a configurable
    2141       option.
    2142   </t></list>
    2143 </t>
     2148</t>
     2149<x:note>
     2150  <t>
     2151    <x:h>Note:</x:h> Revealing the specific software version of the server might
     2152    allow the server machine to become more vulnerable to attacks
     2153    against software that is known to contain security holes. Server
     2154    implementors are encouraged to make this field a configurable
     2155    option.
     2156  </t>
     2157</x:note>
    21442158</section>
    21452159
Note: See TracChangeset for help on using the changeset viewer.