Changeset 1964 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 01/11/12 18:46:15 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1963 r1964 1048 1048 <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> 1049 1049 </pre><p id="rfc.section.3.1.3.2.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 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 'sown preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field1050 users' own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field 1051 1051 is 1052 1052 </p> … … 1242 1242 <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. 1243 1243 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. 1246 1245 </p> 1247 1246 <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 … … 1993 1992 </p> 1994 1993 <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>) 1996 1995 </p> 1997 1996 <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. … … 2124 2123 <div id="rfc.figure.u.40"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2125 2124 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <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 codeof 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> 2127 2126 <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, 2128 2127 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 … … 2135 2134 </p> 2136 2135 <ul> 2137 <li> <a href="#status.1xx" class="smpl">1xx (Informational)</a>: Requestreceived, continuing process2138 </li> 2139 <li> <a href="#status.2xx" class="smpl">2xx (Successful)</a>: The actionwas successfully received, understood, and accepted2136 <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 2140 2139 </li> 2141 2140 <li> <a href="#status.3xx" class="smpl">3xx (Redirection)</a>: Further action needs to be taken in order to complete the request … … 2324 2323 <tr> 2325 2324 <td class="left">416</td> 2326 <td class="left">Requested range not satisfiable</td>2325 <td class="left">Requested Range Not Satisfiable</td> 2327 2326 <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> 2328 2327 </tr> … … 2426 2425 (e.g., in the case of a response to a PUT request). 2427 2426 </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. 2429 2428 </p> 2430 2429 <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 … … 3507 3506 </li> 3508 3507 <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>). 3510 3509 </p> 3511 3510 </li> … … 4088 4087 </p> 4089 4088 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <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 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 3.1.4.2</a>) 4092 4091 </p> 4093 4092 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>)
Note: See TracChangeset
for help on using the changeset viewer.