Changeset 2074 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 31/12/12 11:51:04 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2073 r2074 1340 1340 </t> 1341 1341 <t> 1342 If one or more resources has been created on the origin server, the response 1343 &SHOULD; be <x:ref>201 (Created)</x:ref>, contain a representation which 1344 describes the status of the request and refers to the new resource(s), and 1345 include a <x:ref>Location</x:ref> header field that provides an identifier 1346 for the primary resource created (see <xref target="header.location"/>). 1342 If one or more resources has been created on the origin server, the origin 1343 server &SHOULD; send a <x:ref>201 (Created)</x:ref> response containing a 1344 <x:ref>Location</x:ref> header field that provides an identifier for the 1345 primary resource created (<xref target="header.location"/>) and a 1346 representation that describes the status of the request and refers to the 1347 new resource(s). 1347 1348 </t> 1348 1349 <t> 1349 1350 Responses to POST requests are only cacheable when they include explicit 1350 freshness information (see &p6-explicit;). A cache d POST response with a1351 <x:ref>Content-Location</x:ref> header field (see1352 &header-content-location;) whose value is the effective Request URI &MAY;1353 be used to satisfy subsequent GET and HEAD (not POST) requests.1351 freshness information (see &p6-explicit;). A cache &MUST-NOT; use a cached 1352 POST response to satisfy a subsequent GET or HEAD request unless the 1353 response contains a <x:ref>Content-Location</x:ref> header field with the 1354 same value as the POST's effective request URI (&header-content-location;). 1354 1355 </t> 1355 1356 <t> … … 1393 1394 <t> 1394 1395 An origin server &SHOULD; verify that the PUT representation is 1395 consistent with any constraints whichthe server has for the target1396 consistent with any constraints the server has for the target 1396 1397 resource that cannot or will not be changed by the PUT. This is 1397 1398 particularly important when the origin server uses internal … … 1460 1461 A PUT request applied to the target resource &MAY; have side-effects 1461 1462 on other resources. For example, an article might have a URI for 1462 identifying "the current version" (a resource) whichis separate1463 identifying "the current version" (a resource) that is separate 1463 1464 from the URIs identifying each particular version (different 1464 1465 resources that at one point shared the same state as the current version … … 1600 1601 </t> 1601 1602 <t> 1602 An origin server whichreceives a CONNECT request for itself &MAY;1603 An origin server that receives a CONNECT request for itself &MAY; 1603 1604 respond with a <x:ref>2xx</x:ref> status code to indicate that a connection 1604 1605 is established. However, most origin servers do not implement CONNECT. … … 1741 1742 methods to limit the number of times that the request is forwarded by 1742 1743 proxies. This can be useful when the client is attempting to 1743 trace a request whichappears to be failing or looping mid-chain.1744 trace a request that appears to be failing or looping mid-chain. 1744 1745 </t> 1745 1746 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/> … … 1860 1861 Requirements for HTTP/1.1 origin servers: 1861 1862 <list style="symbols"> 1862 <t> Upon receiving a request whichincludes an <x:ref>Expect</x:ref> header1863 <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header 1863 1864 field with the "100-continue" expectation, an origin server &MUST; 1864 1865 either respond with <x:ref>100 (Continue)</x:ref> status code and … … 2099 2100 The media type quality factor associated with a given type is 2100 2101 determined by finding the media range with the highest precedence 2101 which matches thattype. For example,2102 that matches the type. For example, 2102 2103 </t> 2103 2104 <figure><artwork type="example"> … … 2120 2121 &Note; A user agent might be provided with a default set of quality 2121 2122 values for certain media ranges. However, unless the user agent is 2122 a closed system whichcannot interact with other rendering agents,2123 a closed system that cannot interact with other rendering agents, 2123 2124 this default set ought to be configurable by the user. 2124 2125 </t> … … 2133 2134 This field allows user agents capable of understanding more comprehensive 2134 2135 or special-purpose charsets to signal that capability to an origin server 2135 whichis capable of representing documents in those charsets.2136 that is capable of representing documents in those charsets. 2136 2137 </t> 2137 2138 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/> … … 2149 2150 <t> 2150 2151 The special value "*", if present in the Accept-Charset field, 2151 matches every charset whichis not mentioned elsewhere in the2152 matches every charset that is not mentioned elsewhere in the 2152 2153 Accept-Charset field. If no "*" is present in an Accept-Charset field, 2153 2154 then any charsets not explicitly mentioned in the field are … … 2187 2188 </artwork></figure> 2188 2189 <t> 2189 Each codings value &MAY; be given an associated quality value which2190 represent sthe preference for that encoding, as defined in &qvalue;.2190 Each codings value &MAY; be given an associated quality value 2191 representing the preference for that encoding, as defined in &qvalue;. 2191 2192 </t> 2192 2193 <t> … … 2258 2259 </artwork></figure> 2259 2260 <t> 2260 Each language-range can be given an associated quality value which2261 represent san estimate of the user's preference for the languages2261 Each language-range can be given an associated quality value 2262 representing an estimate of the user's preference for the languages 2262 2263 specified by that range, as defined in &qvalue;. For example, 2263 2264 </t> … … 2665 2666 a change in the application protocol being used on this connection. The 2666 2667 server will switch to the protocol(s) indicated within the response's 2667 Upgrade header field immediately after the empty line whichterminates the2668 Upgrade header field immediately after the empty line that terminates the 2668 2669 101 response. 2669 2670 </t> … … 3204 3205 <t> 3205 3206 The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the 3206 <x:ref>target resource</x:ref> does not have a current representation which3207 <x:ref>target resource</x:ref> does not have a current representation that 3207 3208 would be acceptable to the user agent, according to the 3208 3209 <x:ref>proactive negotiation</x:ref> header fields received in the request … … 3252 3253 Conflicts are most likely to occur in response to a PUT request. For 3253 3254 example, if versioning were being used and the representation being PUT 3254 included changes to a resource whichconflict with those made by an3255 included changes to a resource that conflict with those made by an 3255 3256 earlier (third-party) request, the origin server might use a 409 response 3256 3257 to indicate that it can't complete the request. In this case, the response … … 3403 3404 <t> 3404 3405 The <x:dfn>500 (Internal Server Error)</x:dfn> status code indicates that 3405 the server encountered an unexpected condition whichprevented it from3406 the server encountered an unexpected condition that prevented it from 3406 3407 fulfilling the request. 3407 3408 </t> … … 4761 4762 The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or 4762 4763 <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can 4763 sometimes be used to determine that a specific client or server has a4764 particular security hole which might be exploited. Unfortunately, this same4764 sometimes be used to determine if a specific client or server is more 4765 likely to be vulnerable to a known security hole. Unfortunately, this same 4765 4766 information is often used for other valuable purposes for which HTTP 4766 4767 currently has no better mechanism. … … 4834 4835 <t> 4835 4836 Accept header fields can reveal information about the user to all 4836 servers whichare accessed. The <x:ref>Accept-Language</x:ref> header field4837 servers that are accessed. The <x:ref>Accept-Language</x:ref> header field 4837 4838 in particular can reveal information the user would consider to be of a 4838 4839 private nature, because the understanding of particular languages is often 4839 4840 strongly correlated to the membership of a particular ethnic group. 4840 User agents whichoffer the option to configure the contents of an4841 User agents that offer the option to configure the contents of an 4841 4842 Accept-Language header field to be sent in every request are strongly 4842 4843 encouraged to let the configuration process include a message which … … 4864 4865 header field configuration options to end users. As an extreme privacy 4865 4866 measure, proxies could filter the accept header fields in relayed requests. 4866 General purpose user agents whichprovide a high degree of header field4867 General purpose user agents that provide a high degree of header field 4867 4868 configurability &SHOULD; warn users about the loss of privacy which can 4868 4869 be involved. … … 5648 5649 environment &SHOULD; translate all line breaks within the text media 5649 5650 types described in <xref target="canonicalization.and.text.defaults"/> 5650 of this document to the RFC 2049 canonical form of CRLF. Note, however, that5651 of this document to the RFC 2049 canonical form of CRLF. Note, however, 5651 5652 this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref> 5652 5653 and by the fact that HTTP allows the use of some charsets 5653 whichdo not use octets 13 and 10 to represent CR and LF, respectively.5654 that do not use octets 13 and 10 to represent CR and LF, respectively. 5654 5655 </t> 5655 5656 <t> … … 5707 5708 <section title="MHTML and Line Length Limitations" anchor="mhtml.line.length"> 5708 5709 <t> 5709 HTTP implementations whichshare code with MHTML <xref target="RFC2557"/> implementations5710 HTTP implementations that share code with MHTML <xref target="RFC2557"/> implementations 5710 5711 need to be aware of MIME line length limitations. Since HTTP does not 5711 5712 have this limitation, HTTP does not fold long lines. MHTML messages
Note: See TracChangeset
for help on using the changeset viewer.