Changeset 879
- Timestamp:
- 23/07/10 09:19:25 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r878 r879 2136 2136 <li> 2137 2137 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 2138 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 6.4</a>, a qvalue of 0 means "not acceptable .")2138 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 6.4</a>, a qvalue of 0 means "not acceptable".) 2139 2139 </p> 2140 2140 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r877 r879 3141 3141 listed in the TE field, then it is acceptable unless it 3142 3142 is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a 3143 qvalue of 0 means "not acceptable .")</t>3143 qvalue of 0 means "not acceptable".)</t> 3144 3144 </x:lt> 3145 3145 <x:lt> -
draft-ietf-httpbis/latest/p3-payload.html
r878 r879 715 715 </p> 716 716 <div class="note" id="rfc.section.2.1.p.3"> 717 <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding ."However, since HTTP and MIME717 <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding". However, since HTTP and MIME 718 718 share the same registry, it is important that the terminology also be shared. 719 719 </p> … … 736 736 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="missing.charset" href="#missing.charset">Missing Charset</a></h3> 737 737 <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should 738 guess ."Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.738 guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient. 739 739 </p> 740 740 <p id="rfc.section.2.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially … … 1031 1031 <div id="rfc.figure.u.15"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 1032 1032 </pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 1033 quality ."1033 quality". 1034 1034 </p> 1035 1035 <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field … … 1041 1041 text/x-dvi; q=0.8, text/x-c 1042 1042 </pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 1043 send the text/x-dvi representation, and if that does not exist, send the text/plain representation ."1043 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 1044 1044 </p> 1045 1045 <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies … … 1143 1143 <ol> 1144 1144 <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it 1145 is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable .")1145 is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 1146 1146 </li> 1147 1147 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header … … 1189 1189 </p> 1190 1190 <div id="rfc.figure.u.24"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1191 </pre><p id="rfc.section.5.4.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>)1191 </pre><p id="rfc.section.5.4.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>) 1192 1192 </p> 1193 1193 <p id="rfc.section.5.4.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. … … 1249 1249 it is intended. 1250 1250 </p> 1251 <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi ,"presented1251 <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented 1252 1252 simultaneously in the original Maori and English versions, would call for 1253 1253 </p> 1254 1254 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Language: mi, en 1255 1255 </pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 1256 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin ,"which is clearly1256 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 1257 1257 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 1258 1258 </p> -
draft-ietf-httpbis/latest/p3-payload.xml
r874 r879 408 408 <t> 409 409 <x:h>Note:</x:h> This use of the term "character set" is more commonly 410 referred to as a "character encoding ."However, since HTTP and410 referred to as a "character encoding". However, since HTTP and 411 411 MIME share the same registry, it is important that the terminology 412 412 also be shared. … … 444 444 <t> 445 445 Some HTTP/1.0 software has interpreted a Content-Type header without 446 charset parameter incorrectly to mean "recipient should guess ."446 charset parameter incorrectly to mean "recipient should guess". 447 447 Senders wishing to defeat this behavior &MAY; include a charset 448 448 parameter even when the charset is ISO-8859-1 (<xref target="ISO-8859-1"/>) and &SHOULD; do so when … … 1029 1029 <t> 1030 1030 &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio 1031 type if it is the best available after an 80% mark-down in quality ."1031 type if it is the best available after an 80% mark-down in quality". 1032 1032 </t> 1033 1033 <t> … … 1049 1049 the preferred media types, but if they do not exist, then send the 1050 1050 text/x-dvi representation, and if that does not exist, send the text/plain 1051 representation ."1051 representation". 1052 1052 </t> 1053 1053 <t> … … 1180 1180 the Accept-Encoding field, then it is acceptable, unless it is 1181 1181 accompanied by a qvalue of 0. (As defined in &qvalue;, a 1182 qvalue of 0 means "not acceptable .")</t>1182 qvalue of 0 means "not acceptable".)</t> 1183 1183 1184 1184 <t>The special "*" symbol in an Accept-Encoding field matches any … … 1261 1261 <t> 1262 1262 would mean: "I prefer Danish, but will accept British English and 1263 other types of English ."1263 other types of English". 1264 1264 (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>) 1265 1265 </t> … … 1386 1386 Multiple languages &MAY; be listed for content that is intended for 1387 1387 multiple audiences. For example, a rendition of the "Treaty of 1388 Waitangi ,"presented simultaneously in the original Maori and English1388 Waitangi", presented simultaneously in the original Maori and English 1389 1389 versions, would call for 1390 1390 </t> … … 1396 1396 does not mean that it is intended for multiple linguistic audiences. 1397 1397 An example would be a beginner's language primer, such as "A First 1398 Lesson in Latin ,"which is clearly intended to be used by an1398 Lesson in Latin", which is clearly intended to be used by an 1399 1399 English-literate audience. In this case, the Content-Language would 1400 1400 properly only include "en". -
draft-ietf-httpbis/latest/p4-conditional.html
r878 r879 638 638 </pre><p id="rfc.section.2.p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality. 639 639 </p> 640 <p id="rfc.section.2.p.4">A "weak entity-tag ,"indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each640 <p id="rfc.section.2.p.4">A "weak entity-tag", indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each 641 641 other with no significant change in semantics. A weak entity-tag can only be used for weak comparison. 642 642 </p> … … 711 711 one normally would expect that if the representation (including both representation header fields and representation body) 712 712 changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong 713 validator ."713 validator". 714 714 </p> 715 715 <p id="rfc.section.4.p.2">However, there might be cases when a server prefers to change the validator only on semantically significant changes, and 716 716 not when insignificant aspects of the representation change. A validator that does not always change when the representation 717 changes is a "weak validator ."718 </p> 719 <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak ."One can717 changes is a "weak validator". 718 </p> 719 <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak". One can 720 720 think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value 721 721 changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an -
draft-ietf-httpbis/latest/p4-conditional.xml
r874 r879 330 330 </t> 331 331 <t> 332 A "weak entity-tag ,"indicated by the "W/" prefix, &MAY; be shared by332 A "weak entity-tag", indicated by the "W/" prefix, &MAY; be shared by 333 333 two representations of a resource only if the representations are equivalent and 334 334 could be substituted for each other with no significant change in … … 460 460 header fields and representation body) changes in any way, then the 461 461 associated validator would change as well. If this is true, then we 462 call this validator a "strong validator ."462 call this validator a "strong validator". 463 463 </t> 464 464 <t> … … 466 466 validator only on semantically significant changes, and not when 467 467 insignificant aspects of the representation change. A validator that does not 468 always change when the representation changes is a "weak validator ."468 always change when the representation changes is a "weak validator". 469 469 </t> 470 470 <t> 471 471 An entity-tag is normally a strong validator, but the protocol 472 provides a mechanism to tag an entity-tag as "weak ."One can think of472 provides a mechanism to tag an entity-tag as "weak". One can think of 473 473 a strong validator as one that changes whenever the sequence of bits 474 474 in a representation changes, while a weak value changes whenever the
Note: See TracChangeset
for help on using the changeset viewer.