Changeset 866


Ignore:
Timestamp:
Jul 22, 2010, 2:06:27 AM (9 years ago)
Author:
fielding@…
Message:

Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with representation.

Location:
draft-ietf-httpbis/latest
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r864 r866  
    28102810<t>
    28112811   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.
    28132813</t>
    28142814
    … …  
    31933193</artwork></figure>
    31943194<t>
    3195    If multiple encodings have been applied to an entity, the transfer-codings
     3195   If multiple encodings have been applied to a representation, the transfer-codings
    31963196   &MUST; be listed in the order in which they were applied.
    31973197   Additional information about the encoding parameters &MAY; be provided

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r858 r866  
    602602   safely assume that there was something wrong with its request and
    603603   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 returned
    605    with the response, since that entity is likely to include human-readable
     604   cases, user agents &SHOULD; present to the user the representation enclosed
     605   with the response, since that representation is likely to include human-readable
    606606   information which will explain the unusual status.
    607607</t>
    … …  
    654654</section>
    655655
    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
    667668   from the message-body by decoding any Transfer-Encoding that might
    668669   have been applied to ensure safe and proper transfer of the message.
    … …  
    838839<t>   
    839840   If the Effective Request URI identifies a data-producing process, it is the
    840    produced data which shall be returned as the entity in the response and not
     841   produced data which shall be returned as the representation in the response and not
    841842   the source text of the process, unless that text happens to be the output of
    842843   the process.
    … …  
    846847   request message includes an If-Modified-Since, If-Unmodified-Since,
    847848   If-Match, If-None-Match, or If-Range header field. A conditional GET
    848    method requests that the entity be transferred only under the
     849   method requests that the representation be transferred only under the
    849850   circumstances described by the conditional header field(s). The
    850851   conditional GET method is intended to reduce unnecessary network
    … …  
    855856   The semantics of the GET method change to a "partial GET" if the
    856857   request message includes a Range header field. A partial GET requests
    857    that only part of the entity be transferred, as described in &header-range;.
     858   that only part of the representation be transferred, as described in &header-range;.
    858859   The partial GET method is intended to reduce unnecessary
    859    network usage by allowing partially-retrieved entities to be
     860   network usage by allowing partially-retrieved representations to be
    860861   completed without transferring data already held by the client.
    861862</t>
    … …  
    880881   in the HTTP headers in response to a HEAD request &SHOULD; be identical
    881882   to the information sent in response to a GET request. This method can
    882    be used for obtaining metainformation about the entity implied by the
    883    request without transferring the entity-body itself. This method is
     883   be used for obtaining metainformation about the representation implied by the
     884   request without transferring the representation body. This method is
    884885   often used for testing hypertext links for validity, accessibility,
    885886   and recent modification.
    … …  
    950951  <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
    951952<t>
    952    The PUT method requests that the enclosed entity be stored at the
     953   The PUT method requests that the enclosed representation be stored at the
    953954   Effective Request URI. If the Effective Request URI refers to an already
    954    existing resource, the enclosed entity &SHOULD; be considered as a
     955   existing resource, the enclosed representation &SHOULD; be considered a
    955956   modified version of the one residing on the origin server. Otherwise, if the
    956957   Effective Request URI does not point to an existing resource, and that URI is
    … …  
    966967</t>
    967968<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-*
    971973   headers (headers starting with the prefix "Content-") that it does
    972974   not understand or implement
    … …  
    974976</t>
    975977<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.
    979982</t>
    980983<t>
    … …  
    982985   reflected in the different meaning of the Effective Request URI. The URI in a
    983986   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.
    989993   If the server desires that the request be applied to a different URI,
    990994   it &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;
    … …  
    10281032   entity describing the status, 202 (Accepted) if the action has not
    10291033   yet been enacted, or 204 (No Content) if the action has been enacted
    1030    but the response does not include an entity.
     1034   but the response does not include a representation.
    10311035</t>
    10321036<t>
    … …  
    10491053   entity-body of a 200 (OK) response. The final recipient is either the
    10501054   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 request
    1052    &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.
    10531057</t>
    10541058<t>
    … …  
    12171221   batch-oriented process that is only run once per day) without
    12181222   requiring that the user agent's connection to the server persist
    1219    until the process is completed. The entity returned with this
     1223   until the process is completed. The representation returned with this
    12201224   response &SHOULD; include an indication of the request's current status
    12211225   and either a pointer to a status monitor or some estimate of when the
    … …  
    12761280   user input, followed by a clearing of the form in which the input is
    12771281   given so that the user can easily initiate another input action. The
    1278    response &MUST-NOT; include an entity.
     1282   response &MUST-NOT; include a message-body.
    12791283</t>
    12801284</section>
    … …  
    13231327</t>
    13241328<t>
    1325    Unless it was a HEAD request, the response &SHOULD; include an entity
     1329   Unless it was a HEAD request, the response &SHOULD; include a representation
    13261330   containing a list of resource characteristics and location(s) from
    13271331   which the user or user agent can choose the one most appropriate. The
    1328    entity format is specified by the media type given in the Content-Type
     1332   data format is specified by the media type given in the Content-Type
    13291333   header field. Depending upon the format and the capabilities of
    13301334   the user agent, selection of the most appropriate choice &MAY; be
    … …  
    13531357<t>
    13541358   The new permanent URI &SHOULD; be given by the Location field in the
    1355    response. Unless the request method was HEAD, the entity of the
     1359   response. Unless the request method was HEAD, the representation of the
    13561360   response &SHOULD; contain a short hypertext note with a hyperlink to
    13571361   the new URI(s).
    … …  
    13861390<t>
    13871391   The temporary URI &SHOULD; be given by the Location field in the
    1388    response. Unless the request method was HEAD, the entity of the
     1392   response. Unless the request method was HEAD, the representation of the
    13891393   response &SHOULD; contain a short hypertext note with a hyperlink to
    13901394   the new URI(s).
    … …  
    14521456   A 303 response &SHOULD-NOT; be cached unless it is indicated as
    14531457   cacheable by Cache-Control or Expires header fields.  Except for
    1454    responses to a HEAD request, the entity of a 303 response &SHOULD;
     1458   responses to a HEAD request, the representation of a 303 response &SHOULD;
    14551459   contain a short hypertext note with a hyperlink to the Location URI.
    14561460</t>
    … …  
    14991503<t>
    15001504   The temporary URI &SHOULD; be given by the Location field in the
    1501    response. Unless the request method was HEAD, the entity of the
     1505   response. Unless the request method was HEAD, the representation of the
    15021506   response &SHOULD; contain a short hypertext note with a hyperlink to
    15031507   the new URI(s) , since many pre-HTTP/1.1 user agents do not
    … …  
    15731577   If the request method was not HEAD and the server wishes to make
    15741578   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 to
     1579   reason for the refusal in the representation.  If the server does not wish to
    15761580   make this information available to the client, the status code 404
    15771581   (Not Found) can be used instead.
    … …  
    16141618</t>
    16151619<t>
    1616    Unless it was a HEAD request, the response &SHOULD; include an entity
    1617    containing a list of available entity characteristics 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)
    16181622   from which the user or user agent can choose the one most
    1619    appropriate. The entity format is specified by the media type given
     1623   appropriate. The data format is specified by the media type given
    16201624   in the Content-Type header field. Depending upon the format and the
    16211625   capabilities of the user agent, selection of the most appropriate
    … …  
    16731677<t>
    16741678   Conflicts are most likely to occur in response to a PUT request. For
    1675    example, if versioning were being used and the entity being PUT
     1679   example, if versioning were being used and the representation being PUT
    16761680   included changes to a resource which conflict with those made by an
    16771681   earlier (third-party) request, the server might use the 409 response
    16781682   to indicate that it can't complete the request. In this case, the
    1679    response entity would likely contain a list of the differences
     1683   response representation would likely contain a list of the differences
    16801684   between the two versions in a format defined by the response
    16811685   Content-Type.
    … …  
    17681772  <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/>
    17691773<t>
    1770    The server is refusing to service the request because the entity of
     1774   The server is refusing to service the request because the representation of
    17711775   the request is in a format not supported by the requested resource
    17721776   for the requested method.
    … …  
    19021906<t>
    19031907   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.
    19051909</t>
    19061910
    … …  
    20942098  <t>
    20952099    <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs
    2096     from Location in that the Content-Location identifies the original
    2097     location of the entity enclosed in the response. It is therefore
    2098     possible for a response to contain header fields for both Location
    2099     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.
    21002104  </t>
    21012105</x:note>
    … …  
    26952699<t>
    26962700   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.
    26982702   Clients &SHOULD; be careful with sensitive information, like Cookies,
    26992703   Authorization credentials and other headers that might be used to

  • draft-ietf-httpbis/latest/p3-payload.xml

    r864 r866  
    465465<t>
    466466   Content coding values indicate an encoding transformation that has
    467    been or can be applied to an entity. Content codings are primarily
    468    used to allow a document to be compressed or otherwise usefully
     467   been or can be applied to a representation. Content codings are primarily
     468   used to allow a representation to be compressed or otherwise usefully
    469469   transformed without losing the identity of its underlying media type
    470    and without loss of information. Frequently, the entity is stored in
     470   and without loss of information. Frequently, the representation is stored in
    471471   coded form, transmitted directly, and only decoded by the recipient.
    472472</t>
    … …  
    707707<section title="Entity" anchor="entity">
    708708<t>
    709    Request and Response messages &MAY; transfer an entity if not otherwise
    710    restricted by the request method or response status code. An entity
    711    consists of entity-header fields and an entity-body, although some
     709   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
    712712   responses will only include the entity-headers.
    713713</t>
    714714<t>
    715715   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.
    717717</t>
    718718
    … …  
    966966<t>
    967967   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.
    969969</t>
    970970
    … …  
    10491049   Verbally, this would be interpreted as "text/html and text/x-c are
    10501050   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/plain
    1052    entity."
     1051   text/x-dvi representation, and if that does not exist, send the text/plain
     1052   representation."
    10531053</t>
    10541054<t>
    … …  
    13111311<t>
    13121312   The "Content-Encoding" entity-header field indicates what content-codings
    1313    have been applied to the entity-body, and thus what decoding mechanisms
     1313   have been applied to the representation, and thus what decoding mechanisms
    13141314   must be applied in order to obtain the media-type referenced by the
    13151315   Content-Type header field. Content-Encoding is primarily used to allow a
    1316    document to be compressed without losing the identity of its underlying
     1316   representation to be compressed without losing the identity of its underlying
    13171317   media type.
    13181318</t>
    … …  
    13281328</artwork></figure>
    13291329<t>
    1330    The content-coding is a characteristic of the entity identified by
    1331    the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this
     1330   The content-coding is a characteristic of the representation.
     1331   Typically, the representation body is stored with this
    13321332   encoding and is only decoded before rendering or analogous usage.
    13331333   However, a non-transparent proxy &MAY; modify the content-coding if the
    … …  
    13361336</t>
    13371337<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"/>)
    13401341   that lists the non-identity content-coding(s) used.
    13411342</t>
    … …  
    13461347</t>
    13471348<t>
    1348    If multiple encodings have been applied to an entity, the content
     1349   If multiple encodings have been applied to a representation, the content
    13491350   codings &MUST; be listed in the order in which they were applied.
    13501351   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.
    13521353</t>
    13531354</section>
    … …  
    13601361<t>
    13611362   The "Content-Language" entity-header field describes the natural
    1362    language(s) of the intended audience for the entity. Note that this might
     1363   language(s) of the intended audience for the representation. Note that this might
    13631364   not be equivalent to all the languages used within the entity-body.
    13641365</t>
    … …  
    13701371   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    13711372   Content-Language is to allow a user to identify and differentiate
    1372    entities according to the user's own preferred language. Thus, if the
     1373   representations according to the user's own preferred language. Thus, if the
    13731374   body content is intended only for a Danish-literate audience, the
    13741375   appropriate field is
    … …  
    13931394</artwork></figure>
    13941395<t>
    1395    However, just because multiple languages are present within an entity
     1396   However, just because multiple languages are present within a representation
    13961397   does not mean that it is intended for multiple linguistic audiences.
    13971398   An example would be a beginner's language primer, such as "A First
    … …  
    15261527   any transfer-encoding applied to the message-body. If the message is
    15271528   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.
    15291530</t>
    15301531<t>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r863 r866  
    456456<t>
    457457   Since both origin servers and caches will compare two validators to
    458    decide if they represent the same or different entities, one normally
    459    would expect that if the entity (the entity-body or any entity-headers)
    460    changes in any way, then the associated validator would
    461    change as well. If this is true, then we call this validator a
    462    "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."
    463463</t>
    464464<t>
    465465   However, there might be cases when a server prefers to change the
    466466   validator only on semantically significant changes, and not when
    467    insignificant aspects of the entity change. A validator that does not
    468    always change when the resource changes 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."
    469469</t>
    470470<t>
    471471   Entity tags are normally "strong validators," but the protocol
    472472   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.
    478479  <list><t>
    479480      <x:h>Note:</x:h> One example of a strong validator is an integer that is
    480       incremented in stable storage every time an entity is changed.
     481      incremented in stable storage every time a representation is changed.
    481482    </t><t>
    482       An entity's modification time, if represented with one-second
     483      An entity's modification time, if defined with only one-second
    483484      resolution, could be a weak validator, since it is possible that
    484       the resource might be modified twice during a single second.
     485      the representation might be modified twice during a single second.
    485486    </t><t>
    486487      Support for weak validators is optional. However, weak validators
    … …  
    498499<t>
    499500   Strong validators are usable in any context. Weak validators are only
    500    usable in contexts that do not depend on exact equality of an entity.
    501    For example, either kind is usable for a conditional GET of a full
    502    entity. However, only a strong validator is usable for a sub-range
     501   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
    503504   retrieval, since otherwise the client might end up with an internally
    504    inconsistent entity.
     505   inconsistent representation.
    505506</t>
    506507<t>
    … …  
    562563  <list style="symbols">
    563564     <t>The validator is being compared by an origin server to the
    564         actual current validator for the entity and,</t>
    565      <t>That origin server reliably knows that the associated entity did
     565        actual current validator for the representation and,</t>
     566     <t>That origin server reliably knows that the associated representation did
    566567        not change twice during the second covered by the presented
    567568        validator.</t>
    … …  
    573574     <t>The validator is about to be used by a client in an If-Modified-Since
    574575        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>
    576577     <t>That cache entry includes a Date value, which gives the time
    577578        when the origin server sent the original response, and</t>
    … …  
    584585  <list style="symbols">
    585586     <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>
    587588     <t>That cache entry includes a Date value, which gives the time
    588589        when the origin server sent the original response, and</t>
    … …  
    726727<t>
    727728   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.
    729730</t>
    730731
    … …  
    796797</artwork></figure>
    797798<t>
    798    If any of the entity tags match the entity tag of the entity that
     799   If any of the entity tags match the entity tag of the representation that
    799800   would have been returned in the response to a similar GET request
    800801   (without the If-Match header) on that resource, or if "*" is given
    … …  
    805806<t>
    806807   If none of the entity tags match, or if "*" is given and no current
    807    entity exists, the server &MUST-NOT; perform the requested method, and
     808   representation exists, the server &MUST-NOT; perform the requested method, and
    808809   &MUST; return a 412 (Precondition Failed) response. This behavior is
    809810   most useful when the client wants to prevent an updating method, such
    … …  
    825826   A request intended to update a resource (e.g., a PUT) &MAY; include an
    826827   If-Match header field to signal that the request method &MUST-NOT; be
    827    applied if the entity corresponding to the If-Match value (a single
     828   applied if the representation corresponding to the If-Match value (a single
    828829   entity tag) is no longer a representation of that resource. This
    829830   allows the user to indicate that they do not wish the request to be
    … …  
    955956</artwork></figure>
    956957<t>
    957    If any of the entity tags match the entity tag of the entity that
     958   If any of the entity tags match the entity tag of the representation that
    958959   would have been returned in the response to a similar GET request
    959960   (without the If-None-Match header) on that resource, or if "*" is
    960    given and any current entity exists for that resource, then the
     961   given and any current representation exists for that resource, then the
    961962   server &MUST-NOT; perform the requested method, unless required to do
    962963   so because the resource's modification date fails to match that
    … …  
    964965   Instead, if the request method was GET or HEAD, the server &SHOULD;
    965966   respond with a 304 (Not Modified) response, including the cache-related
    966    header fields (particularly ETag) of one of the entities that
     967   header fields (particularly ETag) of one of the representations that
    967968   matched. For all other request methods, the server &MUST; respond with
    968969   a status of 412 (Precondition Failed).
    … …  
    10871088</t>
    10881089<t>
    1089    An origin server &SHOULD; obtain the Last-Modified value of the entity
     1090   An origin server &SHOULD; obtain the Last-Modified value of the representation
    10901091   as close as possible to the time that it generates the Date value of
    10911092   its response. This allows a recipient to make an accurate assessment
    1092    of the entity's modification time, especially if the entity changes
     1093   of the entity's modification time, especially if the representation changes
    10931094   near the time that the response is generated.
    10941095</t>

  • draft-ietf-httpbis/latest/p5-range.xml

    r863 r866  
    419419</t>
    420420<t>
    421    If a cache has a stored non-empty set of subranges for an entity, and
     421   If a cache has a stored non-empty set of subranges for a representation, and
    422422   an incoming response transfers another subrange, the cache &MAY;
    423423   combine the new subrange with the existing set if both the following
    … …  
    445445<t>
    446446   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.
    448448</t>
    449449
    … …  
    549549</t>
    550550<t>
    551    Examples of byte-content-range-spec values, assuming that the entity
     551   Examples of byte-content-range-spec values, assuming that the representation
    552552   contains a total of 1234 bytes:
    553553   <list style="symbols">
    … …  
    647647   could use the Range request-header with a conditional GET (using
    648648   either or both of If-Unmodified-Since and If-Match.) However, if the
    649    condition fails because the entity has been modified, the client
     649   condition fails because the representation has been modified, the client
    650650   would then have to make a second request to obtain the entire current
    651    entity-body.
     651   representation.
    652652</t>
    653653<t>
    654654   The "If-Range" request-header field allows a client to "short-circuit" the second
    655    request. Informally, its meaning is "if the entity is unchanged, send
     655   request. Informally, its meaning is "if the representation is unchanged, send
    656656   me the part(s) that I am missing; otherwise, send me the entire new
    657    entity".
     657   representation".
    658658</t>
    659659<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/><iref primary="true" item="Grammar" subitem="If-Range-v"/>
    … …  
    662662</artwork></figure>
    663663<t>
    664    If the client has no entity tag for an entity, but does have a Last-Modified
     664   If the client has no entity tag for a representation, but does have a Last-Modified
    665665   date, it &MAY; use that date in an If-Range header. (The
    666666   server can distinguish between a valid HTTP-date and any form of
    … …  
    672672<t>
    673673   If the entity tag given in the If-Range header matches the current
    674    cache validator for the entity, then the server &SHOULD; provide the
    675    specified sub-range of the entity using 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)
    676676   response. If the cache validator does not match, then the server &SHOULD;
    677    return the entire entity using a 200 (OK) response.
     677   return the entire representation using a 200 (OK) response.
    678678</t>
    679679</section>
    … …  
    685685<section title="Byte Ranges" anchor="byte.ranges">
    686686<t>
    687    Since all HTTP entities are represented in HTTP messages as sequences
     687   Since all HTTP representations are transferred as sequences
    688688   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-range
     689   representation. (However, not all clients and servers need to support byte-range
    690690   operations.)
    691691</t>
    692692<t>
    693693   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).
    695695</t>
    696696<t anchor="rule.ranges-specifier">
    … …  
    705705
    706706   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.
    708708</t>
    709709<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"/>
    … …  
    729729<t>
    730730   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 is
    732    taken to be equal to one less than the current length of the entity-body
     731   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
    733733   in bytes.
    734734</t>
    735735<t>
    736736   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.
    738738</t>
    739739<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/>
    … …  
    743743<t>
    744744   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,
    746746   this form specifies the last N bytes of an entity-body.) If the
    747    entity is shorter than the specified suffix-length, the entire
    748    entity-body is used.
     747   representation is shorter than the specified suffix-length, the entire
     748   representation is used.
    749749</t>
    750750<t>
    … …  
    757757   of 416 (Requested range not satisfiable). Otherwise, the server
    758758   &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.
    760760</t>
    761761<t>
    … …  
    805805<t>
    806806   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, instead
    808    of the entire entity body.
     807   not) to request one or more sub-ranges of the response representation body, instead
     808   of the entire representation body.
    809809</t>
    810810<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
    … …  
    12871287      Notes:
    12881288  <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>
    12911290
    12921291      <t>Although <xref target="RFC2046"/> permits the boundary string to be

  • draft-ietf-httpbis/latest/p6-cache.xml

    r852 r866  
    325325  <list>
    326326    <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>
    328328  </list>
    329329</t>
    … …  
    533533  target="header.expires" />) or the max-age response cache directive (<xref
    534534  target="cache-response-directive" />). Generally, origin servers will assign future
    535   explicit expiration times to responses in the belief that the entity is not likely to
     535  explicit expiration times to responses in the belief that the representation is not likely to
    536536  change in a semantically significant way before the expiration time is reached.
    537537</t>
    … …  
    945945<t>
    946946  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.
    948948</t>
    949949
    … …  
    12231223      server for any reason, it &MUST; generate a 504 (Gateway Timeout) response.</t>
    12241224    <t>Servers &SHOULD; send the must-revalidate directive if and only if failure to
    1225       validate a request on the entity could result in incorrect operation, such as a
     1225      validate a request on the representation could result in incorrect operation, such as a
    12261226      silently unexecuted financial transaction.</t>
    12271227  </list>
    … …  
    14791479  or transformation of a message that might not be reflected in the message. This
    14801480  information is typically used to warn about possible incorrectness introduced by caching
    1481   operations or transformations applied to the entity body of the message.
     1481  operations or transformations applied to the payload of the message.
    14821482</t>
    14831483<t>
    … …  
    15241524      &MUST; be deleted by caches after validation. They can only be generated by a cache
    15251525      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 headers that is
    1527       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)
    15281528      and &MUST-NOT; be deleted by caches after validation, unless a full response is
    15291529      returned, in which case they &MUST; be.</t>
Note: See TracChangeset for help on using the changeset viewer.