Changeset 866
- Timestamp:
- 22/07/10 09:06:27 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r864 r866 2810 2810 <t> 2811 2811 For entity-header fields, both sender and recipient refer to either the 2812 client or the server, depending on who sends and who receives the entity.2812 client or the server, depending on who sends and who receives the message. 2813 2813 </t> 2814 2814 … … 3193 3193 </artwork></figure> 3194 3194 <t> 3195 If multiple encodings have been applied to a n entity, the transfer-codings3195 If multiple encodings have been applied to a representation, the transfer-codings 3196 3196 &MUST; be listed in the order in which they were applied. 3197 3197 Additional information about the encoding parameters &MAY; be provided -
draft-ietf-httpbis/latest/p2-semantics.xml
r858 r866 602 602 safely assume that there was something wrong with its request and 603 603 treat the response as if it had received a 400 status code. In such 604 cases, user agents &SHOULD; present to the user the entity returned605 with the response, since that entityis likely to include human-readable604 cases, user agents &SHOULD; present to the user the representation enclosed 605 with the response, since that representation is likely to include human-readable 606 606 information which will explain the unusual status. 607 607 </t> … … 654 654 </section> 655 655 656 <section title="Entity" anchor="entity"> 657 <t> 658 Request and Response messages &MAY; transfer an entity if not otherwise 659 restricted by the request method or response status code. An entity 660 consists of entity-header fields and an entity-body, although some 661 responses will only include the entity-headers. HTTP entity-body and 662 entity-header fields are defined in &payload;. 663 </t> 664 <t> 665 An entity-body is only present in a message when a message-body is 666 present, as described in &message-body;. The entity-body is obtained 656 <section title="Representation" anchor="entity"> 657 <t> 658 Request and Response messages &MAY; transfer a representation if not otherwise 659 restricted by the request method or response status code. A representation 660 consists of metadata (representation header fields) and data (representation 661 body). When a complete or partial representation is enclosed in an HTTP message, 662 it is referred to as the payload of the message. HTTP representations 663 are defined in &payload;. 664 </t> 665 <t> 666 A representation body is only present in a message when a message-body is 667 present, as described in &message-body;. The representation body is obtained 667 668 from the message-body by decoding any Transfer-Encoding that might 668 669 have been applied to ensure safe and proper transfer of the message. … … 838 839 <t> 839 840 If the Effective Request URI identifies a data-producing process, it is the 840 produced data which shall be returned as the entityin the response and not841 produced data which shall be returned as the representation in the response and not 841 842 the source text of the process, unless that text happens to be the output of 842 843 the process. … … 846 847 request message includes an If-Modified-Since, If-Unmodified-Since, 847 848 If-Match, If-None-Match, or If-Range header field. A conditional GET 848 method requests that the entitybe transferred only under the849 method requests that the representation be transferred only under the 849 850 circumstances described by the conditional header field(s). The 850 851 conditional GET method is intended to reduce unnecessary network … … 855 856 The semantics of the GET method change to a "partial GET" if the 856 857 request message includes a Range header field. A partial GET requests 857 that only part of the entitybe transferred, as described in &header-range;.858 that only part of the representation be transferred, as described in &header-range;. 858 859 The partial GET method is intended to reduce unnecessary 859 network usage by allowing partially-retrieved entities to be860 network usage by allowing partially-retrieved representations to be 860 861 completed without transferring data already held by the client. 861 862 </t> … … 880 881 in the HTTP headers in response to a HEAD request &SHOULD; be identical 881 882 to the information sent in response to a GET request. This method can 882 be used for obtaining metainformation about the entityimplied by the883 request without transferring the entity-body itself. This method is883 be used for obtaining metainformation about the representation implied by the 884 request without transferring the representation body. This method is 884 885 often used for testing hypertext links for validity, accessibility, 885 886 and recent modification. … … 950 951 <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> 951 952 <t> 952 The PUT method requests that the enclosed entitybe stored at the953 The PUT method requests that the enclosed representation be stored at the 953 954 Effective Request URI. If the Effective Request URI refers to an already 954 existing resource, the enclosed entity &SHOULD; be considered asa955 existing resource, the enclosed representation &SHOULD; be considered a 955 956 modified version of the one residing on the origin server. Otherwise, if the 956 957 Effective Request URI does not point to an existing resource, and that URI is … … 966 967 </t> 967 968 <t> 968 If the resource could not be created or modified with the Effective Request 969 URI, an appropriate error response &SHOULD; be given that reflects the nature 970 of the problem. The recipient of the entity &MUST-NOT; ignore any Content-* 969 If the resource identified by the Effective Request URI could not be 970 created or modified, an appropriate error response &SHOULD; be given 971 that reflects the nature of the problem. 972 The recipient of the representation &MUST-NOT; ignore any Content-* 971 973 headers (headers starting with the prefix "Content-") that it does 972 974 not understand or implement … … 974 976 </t> 975 977 <t> 976 If the request passes through a cache and the Effective Request URI 977 identifies one or more currently cached entities, those entries &SHOULD; be 978 treated as stale. Responses to this method are not cacheable. 978 If the request passes through a cache that has one or more stored 979 responses for the Effective Request URI, those stored responses 980 &SHOULD; be marked as stale if the response to the PUT request 981 is a success status. Responses to the PUT method are not cacheable. 979 982 </t> 980 983 <t> … … 982 985 reflected in the different meaning of the Effective Request URI. The URI in a 983 986 POST request identifies the resource that will handle the enclosed 984 entity. That resource might be a data-accepting process, a gateway to 985 some other protocol, or a separate entity that accepts annotations. 986 In contrast, the URI in a PUT request identifies the entity enclosed 987 with the request -- the user agent knows what URI is intended and the 988 server &MUST-NOT; attempt to apply the request to some other resource. 987 representation. That resource might be a data-accepting process, a gateway to 988 some other protocol, or a document that accepts annotations. 989 In contrast, the URI in a PUT request identifies the resource for 990 which enclosed representation is a new or replacement value; the 991 user agent knows what URI is intended and the server &MUST-NOT; attempt 992 to apply the request to some other resource. 989 993 If the server desires that the request be applied to a different URI, 990 994 it &MUST; send a 301 (Moved Permanently) response; the user agent &MAY; … … 1028 1032 entity describing the status, 202 (Accepted) if the action has not 1029 1033 yet been enacted, or 204 (No Content) if the action has been enacted 1030 but the response does not include a n entity.1034 but the response does not include a representation. 1031 1035 </t> 1032 1036 <t> … … 1049 1053 entity-body of a 200 (OK) response. The final recipient is either the 1050 1054 origin server or the first proxy or gateway to receive a Max-Forwards 1051 value of zero (0) in the request (see <xref target="header.max-forwards"/>). A TRACE request1052 &MUST-NOT; include an entity.1055 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 1056 A TRACE request &MUST-NOT; include a message-body. 1053 1057 </t> 1054 1058 <t> … … 1217 1221 batch-oriented process that is only run once per day) without 1218 1222 requiring that the user agent's connection to the server persist 1219 until the process is completed. The entityreturned with this1223 until the process is completed. The representation returned with this 1220 1224 response &SHOULD; include an indication of the request's current status 1221 1225 and either a pointer to a status monitor or some estimate of when the … … 1276 1280 user input, followed by a clearing of the form in which the input is 1277 1281 given so that the user can easily initiate another input action. The 1278 response &MUST-NOT; include a n entity.1282 response &MUST-NOT; include a message-body. 1279 1283 </t> 1280 1284 </section> … … 1323 1327 </t> 1324 1328 <t> 1325 Unless it was a HEAD request, the response &SHOULD; include a n entity1329 Unless it was a HEAD request, the response &SHOULD; include a representation 1326 1330 containing a list of resource characteristics and location(s) from 1327 1331 which the user or user agent can choose the one most appropriate. The 1328 entityformat is specified by the media type given in the Content-Type1332 data format is specified by the media type given in the Content-Type 1329 1333 header field. Depending upon the format and the capabilities of 1330 1334 the user agent, selection of the most appropriate choice &MAY; be … … 1353 1357 <t> 1354 1358 The new permanent URI &SHOULD; be given by the Location field in the 1355 response. Unless the request method was HEAD, the entityof the1359 response. Unless the request method was HEAD, the representation of the 1356 1360 response &SHOULD; contain a short hypertext note with a hyperlink to 1357 1361 the new URI(s). … … 1386 1390 <t> 1387 1391 The temporary URI &SHOULD; be given by the Location field in the 1388 response. Unless the request method was HEAD, the entityof the1392 response. Unless the request method was HEAD, the representation of the 1389 1393 response &SHOULD; contain a short hypertext note with a hyperlink to 1390 1394 the new URI(s). … … 1452 1456 A 303 response &SHOULD-NOT; be cached unless it is indicated as 1453 1457 cacheable by Cache-Control or Expires header fields. Except for 1454 responses to a HEAD request, the entityof a 303 response &SHOULD;1458 responses to a HEAD request, the representation of a 303 response &SHOULD; 1455 1459 contain a short hypertext note with a hyperlink to the Location URI. 1456 1460 </t> … … 1499 1503 <t> 1500 1504 The temporary URI &SHOULD; be given by the Location field in the 1501 response. Unless the request method was HEAD, the entityof the1505 response. Unless the request method was HEAD, the representation of the 1502 1506 response &SHOULD; contain a short hypertext note with a hyperlink to 1503 1507 the new URI(s) , since many pre-HTTP/1.1 user agents do not … … 1573 1577 If the request method was not HEAD and the server wishes to make 1574 1578 public why the request has not been fulfilled, it &SHOULD; describe the 1575 reason for the refusal in the entity. If the server does not wish to1579 reason for the refusal in the representation. If the server does not wish to 1576 1580 make this information available to the client, the status code 404 1577 1581 (Not Found) can be used instead. … … 1614 1618 </t> 1615 1619 <t> 1616 Unless it was a HEAD request, the response &SHOULD; include a n entity1617 containing a list of available entitycharacteristics and location(s)1620 Unless it was a HEAD request, the response &SHOULD; include a representation 1621 containing a list of available representation characteristics and location(s) 1618 1622 from which the user or user agent can choose the one most 1619 appropriate. The entityformat is specified by the media type given1623 appropriate. The data format is specified by the media type given 1620 1624 in the Content-Type header field. Depending upon the format and the 1621 1625 capabilities of the user agent, selection of the most appropriate … … 1673 1677 <t> 1674 1678 Conflicts are most likely to occur in response to a PUT request. For 1675 example, if versioning were being used and the entitybeing PUT1679 example, if versioning were being used and the representation being PUT 1676 1680 included changes to a resource which conflict with those made by an 1677 1681 earlier (third-party) request, the server might use the 409 response 1678 1682 to indicate that it can't complete the request. In this case, the 1679 response entitywould likely contain a list of the differences1683 response representation would likely contain a list of the differences 1680 1684 between the two versions in a format defined by the response 1681 1685 Content-Type. … … 1768 1772 <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/> 1769 1773 <t> 1770 The server is refusing to service the request because the entityof1774 The server is refusing to service the request because the representation of 1771 1775 the request is in a format not supported by the requested resource 1772 1776 for the requested method. … … 1902 1906 <t> 1903 1907 For entity-header fields, both sender and recipient refer to either the 1904 client or the server, depending on who sends and who receives the entity.1908 client or the server, depending on who sends and who receives the message. 1905 1909 </t> 1906 1910 … … 2094 2098 <t> 2095 2099 <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs 2096 from Location in that the Content-Location identifies the original2097 location of the entity enclosed in the response. It is therefore2098 possible for a response to contain header fields for both Location2099 and Content-Location.2100 from Location in that the Content-Location identifies the most specific 2101 resource corresponding to the enclosed representation. 2102 It is therefore possible for a response to contain header fields for 2103 both Location and Content-Location. 2100 2104 </t> 2101 2105 </x:note> … … 2695 2699 <t> 2696 2700 Some methods, like TRACE (<xref target="TRACE"/>) may expose 2697 information sent in request headers in the response entity.2701 information sent in request headers in the response. 2698 2702 Clients &SHOULD; be careful with sensitive information, like Cookies, 2699 2703 Authorization credentials and other headers that might be used to -
draft-ietf-httpbis/latest/p3-payload.xml
r864 r866 465 465 <t> 466 466 Content coding values indicate an encoding transformation that has 467 been or can be applied to a n entity. Content codings are primarily468 used to allow a documentto be compressed or otherwise usefully467 been or can be applied to a representation. Content codings are primarily 468 used to allow a representation to be compressed or otherwise usefully 469 469 transformed without losing the identity of its underlying media type 470 and without loss of information. Frequently, the entityis stored in470 and without loss of information. Frequently, the representation is stored in 471 471 coded form, transmitted directly, and only decoded by the recipient. 472 472 </t> … … 707 707 <section title="Entity" anchor="entity"> 708 708 <t> 709 Request and Response messages &MAY; transfer a n entityif not otherwise710 restricted by the request method or response status code. A n entity711 consists of entity-header fields and a n entity-body, although some709 Request and Response messages &MAY; transfer a representation if not otherwise 710 restricted by the request method or response status code. A representation 711 consists of entity-header fields and a representation body, although some 712 712 responses will only include the entity-headers. 713 713 </t> 714 714 <t> 715 715 In this section, both sender and recipient refer to either the client 716 or the server, depending on who sends and who receives the entity.716 or the server, depending on who sends and who receives the message. 717 717 </t> 718 718 … … 966 966 <t> 967 967 For entity-header fields, both sender and recipient refer to either the 968 client or the server, depending on who sends and who receives the entity.968 client or the server, depending on who sends and who receives the message. 969 969 </t> 970 970 … … 1049 1049 Verbally, this would be interpreted as "text/html and text/x-c are 1050 1050 the preferred media types, but if they do not exist, then send the 1051 text/x-dvi entity, and if that does not exist, send the text/plain1052 entity."1051 text/x-dvi representation, and if that does not exist, send the text/plain 1052 representation." 1053 1053 </t> 1054 1054 <t> … … 1311 1311 <t> 1312 1312 The "Content-Encoding" entity-header field indicates what content-codings 1313 have been applied to the entity-body, and thus what decoding mechanisms1313 have been applied to the representation, and thus what decoding mechanisms 1314 1314 must be applied in order to obtain the media-type referenced by the 1315 1315 Content-Type header field. Content-Encoding is primarily used to allow a 1316 documentto be compressed without losing the identity of its underlying1316 representation to be compressed without losing the identity of its underlying 1317 1317 media type. 1318 1318 </t> … … 1328 1328 </artwork></figure> 1329 1329 <t> 1330 The content-coding is a characteristic of the entity identified by1331 the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this1330 The content-coding is a characteristic of the representation. 1331 Typically, the representation body is stored with this 1332 1332 encoding and is only decoded before rendering or analogous usage. 1333 1333 However, a non-transparent proxy &MAY; modify the content-coding if the … … 1336 1336 </t> 1337 1337 <t> 1338 If the content-coding of an entity is not "identity", then the 1339 response &MUST; include a Content-Encoding entity-header (<xref target="header.content-encoding"/>) 1338 If the content-coding of a representation is not "identity", then the 1339 representation metadata &MUST; include a Content-Encoding header 1340 field (<xref target="header.content-encoding"/>) 1340 1341 that lists the non-identity content-coding(s) used. 1341 1342 </t> … … 1346 1347 </t> 1347 1348 <t> 1348 If multiple encodings have been applied to a n entity, the content1349 If multiple encodings have been applied to a representation, the content 1349 1350 codings &MUST; be listed in the order in which they were applied. 1350 1351 Additional information about the encoding parameters &MAY; be provided 1351 by other entity-header fields not defined by this specification.1352 by other header fields not defined by this specification. 1352 1353 </t> 1353 1354 </section> … … 1360 1361 <t> 1361 1362 The "Content-Language" entity-header field describes the natural 1362 language(s) of the intended audience for the entity. Note that this might1363 language(s) of the intended audience for the representation. Note that this might 1363 1364 not be equivalent to all the languages used within the entity-body. 1364 1365 </t> … … 1370 1371 Language tags are defined in <xref target="language.tags"/>. The primary purpose of 1371 1372 Content-Language is to allow a user to identify and differentiate 1372 entities according to the user's own preferred language. Thus, if the1373 representations according to the user's own preferred language. Thus, if the 1373 1374 body content is intended only for a Danish-literate audience, the 1374 1375 appropriate field is … … 1393 1394 </artwork></figure> 1394 1395 <t> 1395 However, just because multiple languages are present within a n entity1396 However, just because multiple languages are present within a representation 1396 1397 does not mean that it is intended for multiple linguistic audiences. 1397 1398 An example would be a beginner's language primer, such as "A First … … 1526 1527 any transfer-encoding applied to the message-body. If the message is 1527 1528 received with a transfer-encoding, that encoding &MUST; be removed 1528 prior to checking the Content-MD5 value against the received entity.1529 prior to checking the Content-MD5 value against the received representation. 1529 1530 </t> 1530 1531 <t> -
draft-ietf-httpbis/latest/p4-conditional.xml
r863 r866 456 456 <t> 457 457 Since both origin servers and caches will compare two validators to 458 decide if they represent the same or different entities, one normally459 would expect that if the entity (the entity-body or any entity-headers)460 changes in any way, then the associated validator would461 change as well. If this is true, then we call this validator a462 "strong validator."458 decide if they represent the same or different representations, one normally 459 would expect that if the representation (including both representation 460 header fields and representation body) changes in any way, then the 461 associated validator would change as well. If this is true, then we 462 call this validator a "strong validator." 463 463 </t> 464 464 <t> 465 465 However, there might be cases when a server prefers to change the 466 466 validator only on semantically significant changes, and not when 467 insignificant aspects of the entitychange. A validator that does not468 always change when the re sourcechanges is a "weak validator."467 insignificant aspects of the representation change. A validator that does not 468 always change when the representation changes is a "weak validator." 469 469 </t> 470 470 <t> 471 471 Entity tags are normally "strong validators," but the protocol 472 472 provides a mechanism to tag an entity tag as "weak." One can think of 473 a strong validator as one that changes whenever the bits of an entity 474 changes, while a weak value changes whenever the meaning of an entity 475 changes. Alternatively, one can think of a strong validator as part 476 of an identifier for a specific entity, while a weak validator is 477 part of an identifier for a set of semantically equivalent entities. 473 a strong validator as one that changes whenever the sequence of bits 474 in a representation changes, while a weak value changes whenever the 475 meaning of a representation changes. Alternatively, one can think of 476 a strong validator as part of an identifier for a specific representation, 477 whereas a weak validator is part of an identifier for a set of semantically 478 equivalent representations. 478 479 <list><t> 479 480 <x:h>Note:</x:h> One example of a strong validator is an integer that is 480 incremented in stable storage every time a n entityis changed.481 incremented in stable storage every time a representation is changed. 481 482 </t><t> 482 An entity's modification time, if represented withone-second483 An entity's modification time, if defined with only one-second 483 484 resolution, could be a weak validator, since it is possible that 484 the re sourcemight be modified twice during a single second.485 the representation might be modified twice during a single second. 485 486 </t><t> 486 487 Support for weak validators is optional. However, weak validators … … 498 499 <t> 499 500 Strong validators are usable in any context. Weak validators are only 500 usable in contexts that do not depend on exact equality of a n entity.501 For example, either kind is usable for a conditional GET of a full502 entity.However, only a strong validator is usable for a sub-range501 usable in contexts that do not depend on exact equality of a representation. 502 For example, either kind is usable for a normal conditional GET. 503 However, only a strong validator is usable for a sub-range 503 504 retrieval, since otherwise the client might end up with an internally 504 inconsistent entity.505 inconsistent representation. 505 506 </t> 506 507 <t> … … 562 563 <list style="symbols"> 563 564 <t>The validator is being compared by an origin server to the 564 actual current validator for the entityand,</t>565 <t>That origin server reliably knows that the associated entitydid565 actual current validator for the representation and,</t> 566 <t>That origin server reliably knows that the associated representation did 566 567 not change twice during the second covered by the presented 567 568 validator.</t> … … 573 574 <t>The validator is about to be used by a client in an If-Modified-Since 574 575 or If-Unmodified-Since header, because the client 575 has a cache entry for the associated entity, and</t>576 has a cache entry for the associated representation, and</t> 576 577 <t>That cache entry includes a Date value, which gives the time 577 578 when the origin server sent the original response, and</t> … … 584 585 <list style="symbols"> 585 586 <t>The validator is being compared by an intermediate cache to the 586 validator stored in its cache entry for the entity, and</t>587 validator stored in its cache entry for the representation, and</t> 587 588 <t>That cache entry includes a Date value, which gives the time 588 589 when the origin server sent the original response, and</t> … … 726 727 <t> 727 728 For entity-header fields, both sender and recipient refer to either the 728 client or the server, depending on who sends and who receives the entity.729 client or the server, depending on who sends and who receives the message. 729 730 </t> 730 731 … … 796 797 </artwork></figure> 797 798 <t> 798 If any of the entity tags match the entity tag of the entitythat799 If any of the entity tags match the entity tag of the representation that 799 800 would have been returned in the response to a similar GET request 800 801 (without the If-Match header) on that resource, or if "*" is given … … 805 806 <t> 806 807 If none of the entity tags match, or if "*" is given and no current 807 entityexists, the server &MUST-NOT; perform the requested method, and808 representation exists, the server &MUST-NOT; perform the requested method, and 808 809 &MUST; return a 412 (Precondition Failed) response. This behavior is 809 810 most useful when the client wants to prevent an updating method, such … … 825 826 A request intended to update a resource (e.g., a PUT) &MAY; include an 826 827 If-Match header field to signal that the request method &MUST-NOT; be 827 applied if the entitycorresponding to the If-Match value (a single828 applied if the representation corresponding to the If-Match value (a single 828 829 entity tag) is no longer a representation of that resource. This 829 830 allows the user to indicate that they do not wish the request to be … … 955 956 </artwork></figure> 956 957 <t> 957 If any of the entity tags match the entity tag of the entitythat958 If any of the entity tags match the entity tag of the representation that 958 959 would have been returned in the response to a similar GET request 959 960 (without the If-None-Match header) on that resource, or if "*" is 960 given and any current entityexists for that resource, then the961 given and any current representation exists for that resource, then the 961 962 server &MUST-NOT; perform the requested method, unless required to do 962 963 so because the resource's modification date fails to match that … … 964 965 Instead, if the request method was GET or HEAD, the server &SHOULD; 965 966 respond with a 304 (Not Modified) response, including the cache-related 966 header fields (particularly ETag) of one of the entities that967 header fields (particularly ETag) of one of the representations that 967 968 matched. For all other request methods, the server &MUST; respond with 968 969 a status of 412 (Precondition Failed). … … 1087 1088 </t> 1088 1089 <t> 1089 An origin server &SHOULD; obtain the Last-Modified value of the entity1090 An origin server &SHOULD; obtain the Last-Modified value of the representation 1090 1091 as close as possible to the time that it generates the Date value of 1091 1092 its response. This allows a recipient to make an accurate assessment 1092 of the entity's modification time, especially if the entitychanges1093 of the entity's modification time, especially if the representation changes 1093 1094 near the time that the response is generated. 1094 1095 </t> -
draft-ietf-httpbis/latest/p5-range.xml
r863 r866 419 419 </t> 420 420 <t> 421 If a cache has a stored non-empty set of subranges for a n entity, and421 If a cache has a stored non-empty set of subranges for a representation, and 422 422 an incoming response transfers another subrange, the cache &MAY; 423 423 combine the new subrange with the existing set if both the following … … 445 445 <t> 446 446 For entity-header fields, both sender and recipient refer to either the 447 client or the server, depending on who sends and who receives the entity.447 client or the server, depending on who sends and who receives the message. 448 448 </t> 449 449 … … 549 549 </t> 550 550 <t> 551 Examples of byte-content-range-spec values, assuming that the entity551 Examples of byte-content-range-spec values, assuming that the representation 552 552 contains a total of 1234 bytes: 553 553 <list style="symbols"> … … 647 647 could use the Range request-header with a conditional GET (using 648 648 either or both of If-Unmodified-Since and If-Match.) However, if the 649 condition fails because the entityhas been modified, the client649 condition fails because the representation has been modified, the client 650 650 would then have to make a second request to obtain the entire current 651 entity-body.651 representation. 652 652 </t> 653 653 <t> 654 654 The "If-Range" request-header field allows a client to "short-circuit" the second 655 request. Informally, its meaning is "if the entityis unchanged, send655 request. Informally, its meaning is "if the representation is unchanged, send 656 656 me the part(s) that I am missing; otherwise, send me the entire new 657 entity".657 representation". 658 658 </t> 659 659 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/><iref primary="true" item="Grammar" subitem="If-Range-v"/> … … 662 662 </artwork></figure> 663 663 <t> 664 If the client has no entity tag for a n entity, but does have a Last-Modified664 If the client has no entity tag for a representation, but does have a Last-Modified 665 665 date, it &MAY; use that date in an If-Range header. (The 666 666 server can distinguish between a valid HTTP-date and any form of … … 672 672 <t> 673 673 If the entity tag given in the If-Range header matches the current 674 cache validator for the entity, then the server &SHOULD; provide the675 specified sub-range of the entityusing a 206 (Partial Content)674 cache validator for the representation, then the server &SHOULD; provide the 675 specified sub-range of the representation using a 206 (Partial Content) 676 676 response. If the cache validator does not match, then the server &SHOULD; 677 return the entire entityusing a 200 (OK) response.677 return the entire representation using a 200 (OK) response. 678 678 </t> 679 679 </section> … … 685 685 <section title="Byte Ranges" anchor="byte.ranges"> 686 686 <t> 687 Since all HTTP entities are represented in HTTP messagesas sequences687 Since all HTTP representations are transferred as sequences 688 688 of bytes, the concept of a byte range is meaningful for any HTTP 689 entity. (However, not all clients and servers need to support byte-range689 representation. (However, not all clients and servers need to support byte-range 690 690 operations.) 691 691 </t> 692 692 <t> 693 693 Byte range specifications in HTTP apply to the sequence of bytes in 694 the entity-body (not necessarily the same as the message-body).694 the representation body (not necessarily the same as the message-body). 695 695 </t> 696 696 <t anchor="rule.ranges-specifier"> … … 705 705 706 706 A byte range operation &MAY; specify a single range of bytes, or a set 707 of ranges within a single entity.707 of ranges within a single representation. 708 708 </t> 709 709 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-range-set"/><iref primary="true" item="Grammar" subitem="byte-range-spec"/><iref primary="true" item="Grammar" subitem="first-byte-pos"/><iref primary="true" item="Grammar" subitem="last-byte-pos"/> … … 729 729 <t> 730 730 If the last-byte-pos value is absent, or if the value is greater than 731 or equal to the current length of the entity-body, last-byte-pos is732 taken to be equal to one less than the current length of the entity-body731 or equal to the current length of the representation body, last-byte-pos is 732 taken to be equal to one less than the current length of the representation 733 733 in bytes. 734 734 </t> 735 735 <t> 736 736 By its choice of last-byte-pos, a client can limit the number of 737 bytes retrieved without knowing the size of the entity.737 bytes retrieved without knowing the size of the representation. 738 738 </t> 739 739 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/> … … 743 743 <t> 744 744 A suffix-byte-range-spec is used to specify the suffix of the 745 entity-body, of a length given by the suffix-length value. (That is,745 representation body, of a length given by the suffix-length value. (That is, 746 746 this form specifies the last N bytes of an entity-body.) If the 747 entityis shorter than the specified suffix-length, the entire748 entity-bodyis used.747 representation is shorter than the specified suffix-length, the entire 748 representation is used. 749 749 </t> 750 750 <t> … … 757 757 of 416 (Requested range not satisfiable). Otherwise, the server 758 758 &SHOULD; return a response with a status of 206 (Partial Content) 759 containing the satisfiable ranges of the entity-body.759 containing the satisfiable ranges of the representation. 760 760 </t> 761 761 <t> … … 805 805 <t> 806 806 The "Range" request-header field defines the GET method (conditional or 807 not) to request one or more sub-ranges of the response entity-body, instead808 of the entire entitybody.807 not) to request one or more sub-ranges of the response representation body, instead 808 of the entire representation body. 809 809 </t> 810 810 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/> … … 1287 1287 Notes: 1288 1288 <list style="numbers"> 1289 <t>Additional CRLFs may precede the first boundary string in the 1290 entity.</t> 1289 <t>Additional CRLFs may precede the first boundary string in the body.</t> 1291 1290 1292 1291 <t>Although <xref target="RFC2046"/> permits the boundary string to be -
draft-ietf-httpbis/latest/p6-cache.xml
r852 r866 325 325 <list> 326 326 <t>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find 327 out whether a stored response is an equivalent copy of an entity.</t>327 out whether a stored response has an equivalent copy of a representation.</t> 328 328 </list> 329 329 </t> … … 533 533 target="header.expires" />) or the max-age response cache directive (<xref 534 534 target="cache-response-directive" />). Generally, origin servers will assign future 535 explicit expiration times to responses in the belief that the entityis not likely to535 explicit expiration times to responses in the belief that the representation is not likely to 536 536 change in a semantically significant way before the expiration time is reached. 537 537 </t> … … 945 945 <t> 946 946 For entity-header fields, both sender and recipient refer to either the client or the 947 server, depending on who sends and who receives the entity.947 server, depending on who sends and who receives the message. 948 948 </t> 949 949 … … 1223 1223 server for any reason, it &MUST; generate a 504 (Gateway Timeout) response.</t> 1224 1224 <t>Servers &SHOULD; send the must-revalidate directive if and only if failure to 1225 validate a request on the entitycould result in incorrect operation, such as a1225 validate a request on the representation could result in incorrect operation, such as a 1226 1226 silently unexecuted financial transaction.</t> 1227 1227 </list> … … 1479 1479 or transformation of a message that might not be reflected in the message. This 1480 1480 information is typically used to warn about possible incorrectness introduced by caching 1481 operations or transformations applied to the entity bodyof the message.1481 operations or transformations applied to the payload of the message. 1482 1482 </t> 1483 1483 <t> … … 1524 1524 &MUST; be deleted by caches after validation. They can only be generated by a cache 1525 1525 when validating a cached entry, and &MUST-NOT; be generated in any other situation.</t> 1526 <t>2xx Warnings describe some aspect of the entity body or entity headersthat is1527 not rectified by a validation (for example, a lossy compression of the entity bodies)1526 <t>2xx Warnings describe some aspect of the representation that is 1527 not rectified by a validation (for example, a lossy compression of the representation) 1528 1528 and &MUST-NOT; be deleted by caches after validation, unless a full response is 1529 1529 returned, in which case they &MUST; be.</t>
Note: See TracChangeset
for help on using the changeset viewer.