Changeset 1964 for draft-ietf-httpbis


Ignore:
Timestamp:
01/11/12 18:46:15 (10 years ago)
Author:
julian.reschke@…
Message:

editorial improvements (ack Dan W.)

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1963 r1964  
    907907      </p>
    908908      <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
    909          depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple
     909         depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple
    910910         servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
    911911         to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems.
    … …  
    10041004         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
    10051005         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    1006          for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.
     1006         for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoiding any such changes to the protocol.
    10071007      </p>
    10081008      <div id="rfc.iref.r.5"></div>
    … …  
    20682068      <p id="rfc.section.6.2.5.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.
    20692069      </p>
    2070       <p id="rfc.section.6.2.5.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
     2070      <p id="rfc.section.6.2.5.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
    20712071      </p>
    20722072      <p id="rfc.section.6.2.5.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
    … …  
    25112511      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
    25122512      <p id="rfc.section.8.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
    2513          deliberate misassociation of IP addresses and DNS names not protected by DNSSec. Clients need to be cautious in assuming the
    2514          validity of an IP number/DNS name association unless the response is protected by DNSSec (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).
     2513         deliberate misassociation of IP addresses and DNS names not protected by DNSSEC. Clients need to be cautious in assuming the
     2514         validity of an IP number/DNS name association unless the response is protected by DNSSEC (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).
    25152515      </p>
    25162516      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="attack.intermediaries" href="#attack.intermediaries">Intermediaries and Caching</a></h2>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1963 r1964  
    547547   can be understood in isolation.  Many implementations depend on HTTP's
    548548   stateless design in order to reuse proxied connections or dynamically
    549    load balance requests across multiple servers.  Hence, servers &MUST-NOT;
     549   load-balance requests across multiple servers.  Hence, servers &MUST-NOT;
    550550   assume that two requests on the same connection are from the same user
    551551   agent unless the connection is secured and specific to that agent.
    … …  
    758758   the minor version was not incremented for the changes introduced between
    759759   <xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision
    760    is specifically avoiding any such changes to the protocol.
     760   has specifically avoiding any such changes to the protocol.
    761761</t>
    762762</section>
    … …  
    29972997<t>
    29982998   A server that receives a <x:ref>close</x:ref> connection option &MUST;
    2999    initiate a lingering close of the connection after it sends the final
    3000    response to the request that contained <x:ref>close</x:ref>.
     2999   initiate a lingering close (see below) of the connection after it sends the
     3000   final response to the request that contained <x:ref>close</x:ref>.
    30013001   The server &SHOULD; include a <x:ref>close</x:ref> connection option
    30023002   in its final response on that connection. The server &MUST-NOT; process
    … …  
    35933593   HTTP clients rely heavily on the Domain Name Service (DNS), and are thus
    35943594   generally prone to security attacks based on the deliberate misassociation
    3595    of IP addresses and DNS names not protected by DNSSec. Clients need to be
     3595   of IP addresses and DNS names not protected by DNSSEC. Clients need to be
    35963596   cautious in assuming the validity of an IP number/DNS name association unless
    3597    the response is protected by DNSSec (<xref target="RFC4033"/>).
     3597   the response is protected by DNSSEC (<xref target="RFC4033"/>).
    35983598</t>
    35993599</section>

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

    r1963 r1964  
    10481048      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    10491049</pre><p id="rfc.section.3.1.3.2.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;3.1.3.1</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    1050          user's own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field
     1050         users' own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field
    10511051         is
    10521052      </p>
    … …  
    12421242      <p id="rfc.section.3.4.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
    12431243         For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that
    1244          doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
    1245             (Not Acceptable)</a> response.
     1244         doesn't conform to the user agent's preferences is better than sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response.
    12461245      </p>
    12471246      <p id="rfc.section.3.4.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
    … …  
    19931992      </p>
    19941993      <div id="rfc.figure.u.34"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    1995 </pre><p id="rfc.section.6.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
     1994</pre><p id="rfc.section.6.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (See also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
    19961995      </p>
    19971996      <p id="rfc.section.6.3.5.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
    … …  
    21242123      <div id="rfc.figure.u.40"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    21252124</pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="status.codes" href="#status.codes">Response Status Codes</a></h1>
    2126       <p id="rfc.section.7.p.1">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request.</p>
     2125      <p id="rfc.section.7.p.1">The status-code element is a 3-digit integer code giving the result of the attempt to understand and satisfy the request.</p>
    21272126      <p id="rfc.section.7.p.2">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,
    21282127         though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent
    … …  
    21352134      </p>
    21362135      <ul>
    2137          <li> <a href="#status.1xx" class="smpl">1xx (Informational)</a>: Request received, continuing process
    2138          </li>
    2139          <li> <a href="#status.2xx" class="smpl">2xx (Successful)</a>: The action was successfully received, understood, and accepted
     2136         <li> <a href="#status.1xx" class="smpl">1xx (Informational)</a>: The request was received, continuing process
     2137         </li>
     2138         <li> <a href="#status.2xx" class="smpl">2xx (Successful)</a>: The request was successfully received, understood, and accepted
    21402139         </li>
    21412140         <li> <a href="#status.3xx" class="smpl">3xx (Redirection)</a>: Further action needs to be taken in order to complete the request
    … …  
    23242323               <tr>
    23252324                  <td class="left">416</td>
    2326                   <td class="left">Requested range not satisfiable</td>
     2325                  <td class="left">Requested Range Not Satisfiable</td>
    23272326                  <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    23282327               </tr>
    … …  
    24262425         (e.g., in the case of a response to a PUT request).
    24272426      </p>
    2428       <p id="rfc.section.7.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
     2427      <p id="rfc.section.7.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
    24292428      </p>
    24302429      <p id="rfc.section.7.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
    … …  
    35073506         </li>
    35083507         <li>
    3509             <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3508            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    35103509            </p>
    35113510         </li>
    … …  
    40884087      </p>
    40894088      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    4090       <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
    4091          and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
     4089      <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to poor implementation support (which was caused by too many broken servers emitting bogus Content-Location header fields,
     4090         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
    40924091      </p>
    40934092      <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;5.3.3</a>)

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

    r1963 r1964  
    656656   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    657657   Content-Language is to allow a user to identify and differentiate
    658    representations according to the user's own preferred language. Thus, if the
     658   representations according to the users' own preferred language. Thus, if the
    659659   content is intended only for a Danish-literate audience, the
    660660   appropriate field is
    … …  
    10021002   but it cannot expect responses to always honor them. For example, the origin
    10031003   server might not implement proactive negotiation, or it might decide that
    1004    sending a response that doesn't conform to them is better than sending a <x:ref>406
    1005    (Not Acceptable)</x:ref> response.
     1004   sending a response that doesn't conform to the user agent's preferences is
     1005   better than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
    10061006</t>
    10071007<t>
    … …  
    23152315<t>
    23162316   would mean: "I prefer Danish, but will accept British English and
    2317    other types of English".
    2318    (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
     2317   other types of English". (See also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
    23192318</t>
    23202319<t>
    … …  
    25132512<section title="Response Status Codes" anchor="status.codes">
    25142513<t>
    2515    The status-code element is a 3-digit integer result code of the attempt to
    2516    understand and satisfy the request.
     2514   The status-code element is a 3-digit integer code giving the result of the
     2515   attempt to understand and satisfy the request.
    25172516</t>
    25182517<t>
    … …  
    25372536  <list style="symbols">
    25382537    <t>
    2539       <x:ref>1xx (Informational)</x:ref>: Request received, continuing process
     2538      <x:ref>1xx (Informational)</x:ref>: The request was received, continuing
     2539      process
    25402540    </t>
    25412541    <t>
    2542       <x:ref>2xx (Successful)</x:ref>: The action was successfully received,
    2543         understood, and accepted
     2542      <x:ref>2xx (Successful)</x:ref>: The request was successfully received,
     2543      understood, and accepted
    25442544    </t>
    25452545    <t>
    25462546      <x:ref>3xx (Redirection)</x:ref>: Further action needs to be taken in order to
    2547         complete the request
     2547      complete the request
    25482548    </t>
    25492549    <t>
    25502550      <x:ref>4xx (Client Error)</x:ref>: The request contains bad syntax or cannot
    2551         be fulfilled
     2551      be fulfilled
    25522552    </t>
    25532553    <t>
    25542554      <x:ref>5xx (Server Error)</x:ref>: The server failed to fulfill an apparently
    2555         valid request
     2555      valid request
    25562556    </t>
    25572557  </list>
    … …  
    26102610  <c>414</c> <c>URI Too Long</c> <c><xref target="status.414"/></c>
    26112611  <c>415</c> <c>Unsupported Media Type</c> <c><xref target="status.415"/></c>
    2612   <c>416</c> <c>Requested range not satisfiable</c> <c anchor="status.416">&status-416;</c>
     2612  <c>416</c> <c>Requested Range Not Satisfiable</c> <c anchor="status.416">&status-416;</c>
    26132613  <c>417</c> <c>Expectation Failed</c> <c><xref target="status.417"/></c>
    26142614  <c>426</c> <c>Upgrade Required</c> <c><xref target="status.426"/></c>
    … …  
    27462746   The origin server &MUST; create the resource(s) before returning the 201 status
    27472747   code. If the action cannot be carried out immediately, the server &SHOULD;
    2748    respond with <x:ref>202 (Accepted)</x:ref> response instead.
     2748   respond with a <x:ref>202 (Accepted)</x:ref> response instead.
    27492749</t>
    27502750<t>
    … …  
    44114411    <x:lt><t>Whether it is appropriate to list the field-name in the
    44124412    <x:ref>Connection</x:ref> header field (i.e., if the header field is to
    4413     be hop-by-hop, see &header-connection;).</t></x:lt>
     4413    be hop-by-hop; see &header-connection;).</t></x:lt>
    44144414    <x:lt><t>Under what conditions intermediaries are allowed to modify the header
    44154415    field's value, insert or delete it.</t></x:lt>
    … …  
    56535653<t>
    56545654  Remove base URI setting semantics for "<x:ref>Content-Location</x:ref>" due to
    5655   poor implementation support, which was caused by too many broken servers emitting
     5655  poor implementation support (which was caused by too many broken servers emitting
    56565656  bogus Content-Location header fields, and also the potentially undesirable effect
    5657   of potentially breaking relative links in content-negotiated resources.
     5657  of potentially breaking relative links in content-negotiated resources).
    56585658  (<xref target="header.content-location"/>)
    56595659</t>
Note: See TracChangeset for help on using the changeset viewer.