Ignore:
Timestamp:
Nov 1, 2012, 11:46:15 AM (7 years ago)
Author:
julian.reschke@…
Message:

editorial improvements (ack Dan W.)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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>)
Note: See TracChangeset for help on using the changeset viewer.