1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
Entity
Click on the red underlined text to get to the source
... resolutions) or vary in other ways.
entity
The information transferred as the payload of a request or
...
... The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of
entity-header fields ...
... response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as
...
...
representation
An entity included with a response that is subject to content
negotiation, as described in section 12. There may exist multiple
...
...
explicit expiration time
The time at which the origin server intends that an entity should
no longer be returned by a cache without further validation ...
... validator
A protocol element (e.g., an entity tag or a Last-Modified time)
that is used to find out whether a cache ...
... error code,
followed by a MIME-like message containing server information, entity
metainformation, and possible entity-body content. The relationship
...
... MIME-like message containing server information, entity
metainformation, and possible entity-body content. The relationship
between HTTP and MIME ...
... LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
...
... protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7.
...
... Content coding values indicate an encoding transformation that has
been or can be applied to an entity. Content codings are primarily
used to allow a document to be compressed or otherwise usefully
transformed without losing the identity ...
... identity of its underlying media type
and without loss of information. Frequently, the entity is stored in
coded form, transmitted directly, and only decoded by the recipient.
...
... encoding
transformation that has been, can be, or may need to be applied to an
entity-body in order to ensure "safe transport" through the network.
...
... network.
This differs from a content coding in that the transfer coding is a
property of the message, not of the original entity.
transfer-coding = "chunked" | transfer-extension
...
... encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator,
followed by an optional footer containing entity-header fields. This
allows dynamically-produced content to be transferred along with the
...
... footer, which is terminated by an empty line. The purpose of the
footer is to provide an efficient way to supply information about an
entity that is generated dynamically; applications MUST NOT send
header fields in the footer which are not explicitly defined as being
...
... HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding, and MUST ignore transfer coding extensions
they do not understand. A server which receives an entity-body with a
transfer-coding it does not understand SHOULD return 501
(Unimplemented), and close the connection ...
... media types are registered with a canonical form. In
general, an entity-body transferred via HTTP messages MUST be
represented in the appropriate canonical form ...
... CR or LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF ...
... line breaks. This flexibility regarding
line breaks applies only to text media in the entity-body; a bare CR
or LF ...
... header fields and multipart boundaries).
If an entity-body is encoded with a Content-Encoding, the underlying
data MUST be in a form defined above prior to being encoded.
...
... Content-Location header
field (section 14.15) SHOULD be included in the body-part of each
enclosed entity that can be identified by a URL.
...
...
Entity tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 ...
... tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag (section
14.20), If-Match (section 14.25), If-None-Match (section 14.26), and
...
... are used and compared as cache validators is in section 13.3.3. An
entity tag consists of an opaque quoted string, possibly prefixed by
...
... tag = quoted-string
A "strong entity tag" may be shared by two entities of a resource
only if they are equivalent by octet equality.
...
... only if they are equivalent by octet equality.
A "weak entity tag," indicated by the "W/" prefix, may be shared by
...
... could be substituted for each other with no significant change in
semantics. A weak entity tag can only be used for weak comparison.
...
... tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag value may
be used for entities obtained by requests on different URIs ...
... client to request that only part (a range of) the
response entity be included within the response. HTTP/1.1 uses range
...
... Range (section 14.17)
header fields. An entity may be broken down into subranges according
to various structural units.
...
... request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822std11(-> 2822prop) ...
... message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity ...
... entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field ...
... message. Transfer-Encoding is a property of the message, not of the
entity, and thus can be added or removed by any application along the
request/response ...
... request only when the request method (section 5.1.1) allows an
entity-body.
For response messages, whether or not a message-body ...
... method
MUST NOT include a message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
...
... HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in the
message.
...
... both request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the
message being transmitted.
...
... | "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
...
... status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
...
... user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.
...
... Entity ...
...
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code ...
... restricted by the request method or response status code. An entity
consists of entity-header fields ...
... consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers ...
... header fields and an entity-body, although some
responses will only include the entity-headers.
...
... sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
...
... Entity Header Fields ...
... Entity-header fields define optional metainformation about the
entity-body or, if no body is present, about the resource identified
by the request.
...
...
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
...
... Entity Body ...
... entity-body = *OCTET
An entity-body is only present in a message when a message-body is
present, as described in section 4.3. The entity ...
... entity-body is only present in a message when a message-body is
present, as described in section 4.3. The entity-body is obtained
from the message-body by decoding any Transfer-Encoding ...
...
When an entity-body is included with a message, the data type of that
body is determined via the header fields ...
...
The length of an entity-body is the length of the message-body after
any transfer codings have been removed ...
...
Unless the server's response is an error, the response MUST NOT
include entity information other than what can be considered as
communication options (e.g., Allow is appropriate, but Content-Type
...
... The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers
...
... Request-URI refers
to a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.
...
... Range header field. A conditional GET
method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The
...
... Range header field. A partial GET requests
that only part of the entity be transferred, as described in section
14.36. The partial GET method is intended to reduce unnecessary
...
... to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method ...
... be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links ...
... information contained in the response may be used to update a
previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity ...
... previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length ...
... entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5 ...
... POST method is used to request that the destination server accept
the entity enclosed in the request as a new subordinate of the
resource identified by the Request-URI in the Request-Line. POST is
...
... POST method is determined by the
server and is usually dependent on the Request-URI. The posted entity
is subordinate to that URI in the same way that a file is subordinate
...
... URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result.
...
... created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header ...
...
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI ...
... Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
...
... error response SHOULD be given that reflects the nature of the
problem. The recipient of the entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers ...
... URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource may be a data-accepting process, a gateway to
some other protocol, or a separate entity ...
... entity. That resource may be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity ...
... entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI ...
...
A successful response SHOULD be 200 (OK) if the response includes an
entity describing the status, 202 (Accepted) if the action has not
yet been enacted, or 204 (No Content) if the response is OK but does
not include an entity ...
... entity describing the status, 202 (Accepted) if the action has not
yet been enacted, or 204 (No Content) if the response is OK but does
not include an entity.
If the request passes through a cache ...
... SHOULD reflect the message received back to the client as the
entity-body of a 200 (OK) response. The final recipient is either the
origin server or the first proxy or gateway ...
... value of zero (0) in the request (see section 14.31). A TRACE request
MUST NOT include an entity.
TRACE ...
... If successful, the response SHOULD contain the entire request message
in the entity-body, with a Content-Type of "message/http". Responses
to this method ...
... method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the
response;
...
... response;
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body ...
... created resource can be referenced by the URI(s)
returned in the entity of the response, with the most specific URL
for the resource given by a Location header field ...
... user agent's connection to the server persist
until the process is completed. The entity returned with this
response SHOULD include an indication of the request's current status
and either a pointer to a status monitor or some estimate of when the
...
...
The returned metainformation in the entity-header is not the
definitive set as available from the origin server, but is gathered
...
... active document
view. The response MAY include new metainformation in the form of
entity-headers, which SHOULD apply to the document currently in the
user agent ...
... user input, followed by a clearing of the form in which the input is
given so that the user can easily initiate another input action. The
response MUST NOT include an entity.
...
...
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of resource characteristics and location(s) from
which the user or user agent ...
... which the user or user agent can choose the one most appropriate. The
entity format is specified by the media type given in the Content-
Type header field ...
... URL SHOULD be given by the Location
field in the response. Unless the request method was HEAD, the entity
of the response SHOULD contain a short hypertext note with a
hyperlink to the new URI ...
... URL SHOULD be given by the Location
field in the response. Unless the request method was HEAD, the entity
of the response SHOULD contain a short hypertext note with a
hyperlink to the new URI ...
... URL SHOULD be given by the Location
field in the response. Unless the request method was HEAD, the entity
of the response SHOULD contain a short hypertext note with a
hyperlink to the new URI ...
... If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
...
... headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity ...
... entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
...
... headers.
If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the
...
... client seems to have erred. Except when responding to a HEAD request,
the server SHOULD include an entity containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. These status codes ...
... authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity MAY include
relevant diagnostic information ...
... authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity MAY include
relevant diagnostic information. HTTP access authentication ...
... method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. This status code is commonly
used when the server does not wish to reveal exactly why the request
...
...
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s)
...
... HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s)
from which the user or user agent can choose the one most
...
... from which the user or user agent can choose the one most
appropriate. The entity format is specified by the media type given
in the Content-Type ...
... and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that may not be
...
...
Conflicts are most likely to occur in response to a PUT request. If
versioning is being used and the entity being PUT includes changes to
a resource which conflict with those made by an earlier (third-party)
...
... third-party)
request, the server MAY use the 409 response to indicate that it
can't complete the request. In this case, the response entity SHOULD
contain a list of the differences between the two versions in a
...
... Request Entity Too Large ...
...
The server is refusing to process a request because the request
entity is larger than the server is willing or able to process. The
server may close the connection to prevent the client ...
...
The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource
for the requested method ...
... performing the request. Except when responding to a HEAD request, the
server SHOULD include an entity containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. User agents ...
... error situation, and whether it is a temporary or permanent
condition. User agents SHOULD display any included entity to the
user. These response codes are applicable to any request method ...
... 3.1, other than with this error message. The response SHOULD contain
an entity describing why that version is not supported and what other
protocols are supported by that server.
...
... WWW-Authenticate header field containing the (possibly
new) challenge applicable to the requested resource and an entity
explaining the refusal.
...
...
Most HTTP responses include an entity which contains information for
interpretation by a human user. Naturally, it is desirable to supply
...
... interpretation by a human user. Naturally, it is desirable to supply
the user with the "best available" entity corresponding to the
request. Unfortunately for servers and caches, not all users have
...
... the same preferences for what is "best," and not all user agents are
equally capable of rendering all entity types. For that reason, HTTP
has provisions for several mechanisms for "content negotiation ...
... header fields (this specification reserves the field-name Alternates,
as described in appendix 19.6.2.1) or entity-body of the initial
response, with each representation identified by its own URI.
...
... caches without danger; such caches will simply pass the
warning along as an entity-header in the response.
...
... the display of information that might not meet the server's
transparency requirements (in particular, if the displayed entity is
known to be stale). Since the protocol normally allows the user agent
...
...
Our expectation is that servers will assign future explicit
expiration times to responses in the belief that the entity is not
likely to change, in a semantically significant way, before the
expiration time is reached. This normally preserves semantic ...
... fresh.
Neither the entity tag nor the expiration value can impose an
ordering on responses, since it is possible that a later response
...
...
The server then checks that validator against the current validator
for the entity, and, if they match, it responds with a special status
code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
...
... for the entity, and, if they match, it responds with a special status
code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
returns a full response (including entity-body). Thus, we avoid
...
... status
code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
returns a full response (including entity-body). Thus, we avoid
transmitting the full response if the validator matches, and we avoid
...
... cache cannot do
a conditional retrieval if it does not have a validator for the
entity, which means it will not be refreshable after it expires.
...
... cache entry is considered to be valid
if the entity has not been modified since the Last-Modified value.
...
... paradoxes that may arise from the use of modification dates.
Entity Tags are described in section 3.11. The headers used with
...
... Tags are described in section 3.11. The headers used with
entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.
...
... caches will compare two validators to
decide if they represent the same or different entities, one normally
would expect that if the entity (the entity-body or any entity-
...
... decide if they represent the same or different entities, one normally
would expect that if the entity (the entity-body or any entity-
headers ...
... would expect that if the entity (the entity-body or any entity-
headers) changes in any way, then the associated validator would
...
... validator only on semantically significant changes, and not when
insignificant aspects of the entity change. A validator that does not
always change when the resource changes is a "weak validator."
...
... always change when the resource changes is a "weak validator."
Entity tags are normally "strong validators," but the protocol
provides a mechanism to tag ...
... tags are normally "strong validators," but the protocol
provides a mechanism to tag an entity tag as "weak." One can think of
a strong validator as one that changes whenever the bits ...
... tag as "weak." One can think of
a strong validator as one that changes whenever the bits of an entity
changes, while a weak value changes whenever the meaning of an entity
...
... bits of an entity
changes, while a weak value changes whenever the meaning of an entity
changes. Alternatively, one can think of a strong validator as part
of an identifier ...
... changes. Alternatively, one can think of a strong validator as part
of an identifier for a specific entity, while a weak validator is
part of an identifier for a set of semantically equivalent entities.
...
... Note: One example of a strong validator is an integer that is
incremented in stable storage every time an entity is changed.
An entity ...
... entity is changed.
An entity's modification time, if represented with one-second
resolution, could be a weak validator, since it is possible that
...
... context. Weak validators are only
usable in contexts that do not depend on exact equality of an entity.
For example, either kind is usable for a conditional GET of a full
entity ...
... entity.
For example, either kind is usable for a conditional GET of a full
entity. However, only a strong validator is usable for a sub-range
retrieval, since otherwise the client ...
... retrieval, since otherwise the client may end up with an internally
inconsistent entity.
The only function that the HTTP/1.1 ...
... other cases.
An entity tag is strong unless it is explicitly tagged as weak.
Section 3.11 gives the syntax for entity ...
... entity tag is strong unless it is explicitly tagged as weak.
Section 3.11 gives the syntax for entity tags.
...
...
o The validator is being compared by an origin server to the actual
current validator for the entity and,
o That origin server reliably knows that the associated entity did
...
... current validator for the entity and,
o That origin server reliably knows that the associated entity did
not change twice during the second covered by the presented
validator.
...
... client has a cache
entry for the associated entity, and
o That cache entry includes a Date value, which gives the time when
...
... cache to the
validator stored in its cache entry for the entity, and
o That cache entry includes a Date value, which gives the time when
...
... HTTP/1.1 origin servers:
o SHOULD send an entity tag validator unless it is not feasible to
generate one.
...
... tag validator unless it is not feasible to
generate one.
o MAY send a weak entity tag instead of a strong entity tag ...
... tag, if
performance considerations support the use of weak entity tags, or
if it is unfeasible to send a strong entity ...
... entity tags, or
if it is unfeasible to send a strong entity tag.
o SHOULD send a Last-Modified value if it is feasible to send one,
...
... In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity tag and a Last-Modified value.
...
... tag and a Last-Modified value.
In order to be legal, a strong entity tag MUST change whenever the
associated entity ...
... entity tag MUST change whenever the
associated entity value changes in any way. A weak entity tag SHOULD
...
... tag MUST change whenever the
associated entity value changes in any way. A weak entity tag SHOULD
change whenever the associated entity ...
... entity tag SHOULD
change whenever the associated entity changes in a semantically
significant way.
...
...
Note: in order to provide semantically transparent caching, an
origin server must avoid reusing a specific strong entity tag value
for two different entities, or reusing a specific weak entity ...
... entity tag value
for two different entities, or reusing a specific weak entity tag
value for two semantically different entities. Cache ...
... entity tag has been provided by the origin server, MUST
use that entity tag in any cache-conditional request (using
...
... user agent should
provide a way to disable this, in case of difficulty.
o If both an entity tag and a Last-Modified value have been
provided by the origin server, SHOULD use both validators in
...
... cache's own cache entry. This is only an issue when the
request contains both an entity tag and a last-modified-date
validator (If-Modified-Since or If-Unmodified-Since).
...
... HTTP/1.0 clients and caches will ignore entity tags. Generally,
last-modified values received or used by these systems will support
...
... However, in some cases it may be inappropriate for a cache to retain
an entity, or to return it in response to a subsequent request. This
may be because absolute semantic transparency is deemed necessary by
...
... entity-body stored in the cache entry as the entity-body of this
outgoing response. The end-to-end headers ...
... update any header associated with a previous response
for the same entity, although it might not always be meaningful or
correct to do so. This rule does not allow an origin server to use
a 304 (not Modified) response to entirely delete ...
...
A response may transfer only a subrange of the bytes of an entity-
body, either because the request included one or more Range
...
...
If a cache has a stored non-empty set of subranges for an entity, and
an incoming response transfers another subrange, the cache MAY
...
... multiple representations of a cachable response. A cache may use the
selected representation (the entity included with that particular
response) for replying to subsequent requests on that resource only
when the subsequent requests have the same or equivalent values for
...
... be forwarded toward the origin server.
If an entity tag was assigned to the representation, the forwarded
request SHOULD be conditional and include the entity ...
... entity tag was assigned to the representation, the forwarded
request SHOULD be conditional and include the entity tags in an If-
None-Match header field ...
... the cache, so that if any one of these entities matches the requested
entity, the server can use the ETag header in its 304 (Not Modified)
response to tell the cache ...
... response to tell the cache which entry is appropriate. If the
entity-tag of the new response matches that of an existing entry, the
...
... cache relays the new request
to the origin server in a conditional request and the server responds
with 304 (Not Modified), including an entity tag or Content-Location
...
... tag or Content-Location
that indicates which entity should be used.
If any of the existing cache ...
... If any of the existing cache entries contains only partial content
for the associated entity, its entity-tag SHOULD NOT be included in
...
... cache entries contains only partial content
for the associated entity, its entity-tag SHOULD NOT be included in
the If-None-Match header ...
... cache entry for the same Request-
URI, whose entity-tag differs from that of the existing entry, and
whose Date is more recent than that of the existing entry, the
...
... reduce the likelihood of erroneous behavior.
In this section, the phrase "invalidate an entity" means that the
cache should either remove ...
... cache should either remove all instances of that entity from its
storage, or should mark these as "invalid" and in need of a mandatory
revalidation before they can be returned in response to a subsequent
...
... Some HTTP methods may invalidate an entity. This is either the entity
referred to by the Request-URI ...
... HTTP methods may invalidate an entity. This is either the entity
referred to by the Request-URI, or by the Location or Content-
...
... User agents often have history mechanisms, such as "Back" buttons and
history lists, which can be used to redisplay an entity retrieved
earlier in a session.
...
...
By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism should display
it even if the entity has expired, unless the user has specifically
...
... If the entity is still in storage, a history mechanism should display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh ...
... recipient refer to either the client or the server, depending on who
sends and who receives the entity.
...
... the preferred media types, but if they do not exist, then send the
text/x-dvi entity, and if that does not exist, send the text/plain
entity ...
...
The expiration time of an entity may be specified by the origin
server using the Expires header (see section 14.21). Alternatively,
...
... client
with a 200 (OK) response. If the server replies with a new entity and
cache validator, however, the intermediate cache ...
... equal to the origin server's, then the intermediate cache simply
returns 304 (Not Modified). Otherwise, it returns the new entity with
a 200 (OK) response.
...
...
Servers should send the must-revalidate directive if and only if
failure to revalidate a request on the entity could result in
incorrect operation, such as a silently unexecuted financial
transaction ...
... transaction. Recipients MUST NOT take any automated action that
violates this directive, and MUST NOT automatically provide an
unvalidated copy of the entity if revalidation fails.
Although this is not recommended, user agents ...
... proxies) have found it useful to
convert the media type of certain entity bodies. A proxy might, for
example, convert between image ...
... Serious operational problems have already occurred, however, when
these transformations have been applied to entity bodies intended for
certain kinds of applications. For example, applications for medical
imaging, scientific data analysis ...
... data analysis and those using end-to-end
authentication, all depend on receiving an entity body that is bit
for bit ...
... bit
for bit identical to the original entity-body.
Therefore, if a response includes the no-transform directive, an
...
... cache or proxy must not change any
aspect of the entity-body that is specified by these headers.
...
...
The Content-Base entity-header field may be used to specify the base
URI for resolving relative URLs ...
... header field may be used to specify the base
URI for resolving relative URLs within the entity. This header field
is described as Base in RFC 1808(-> 3986std66) ...
... If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location (if that Content-Location ...
... order of precedence. Note, however, that the base URI of the contents
within the entity-body may be redefined within that entity-body.
...
... media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms MUST be applied in order to obtain the media-type
...
...
The Content-Encoding is a characteristic of the entity identified by
the Request-URI. Typically, the entity ...
... entity identified by
the Request-URI. Typically, the entity-body is stored with this
encoding and is only decoded before rendering or analogous usage.
...
...
If multiple encodings have been applied to an entity, the content
codings MUST be listed in the order in which they were applied.
...
... Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
...
... header field describes the natural
language(s) of the intended audience for the enclosed entity. Note
that this may not be equivalent to all the languages used within the
...
... that this may not be equivalent to all the languages used within the
entity-body.
Content-Language ...
...
However, just because multiple languages are present within an entity
does not mean that it is intended for multiple linguistic audiences.
An example would be a beginner's language ...
... message-body, in decimal number of octets, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET.
...
... message-body to be transferred, regardless of the media type of the
entity. It must be possible for the recipient to reliably determine
the end of HTTP/1.1 requests containing an entity ...
... entity. It must be possible for the recipient to reliably determine
the end of HTTP/1.1 requests containing an entity-body, e.g., because
the request has a valid Content-Length ...
...
The Content-Location entity-header field may be used to supply the
resource location for the entity ...
... entity-header field may be used to supply the
resource location for the entity enclosed in the message. In the case
where a resource has multiple entities associated with it, and those
...
... SHOULD provide a Content-Location for the resource corresponding to
the response entity.
Content-Location ...
... header field is present, the value of Content-
Location also defines the base URL for the entity (see section
14.11).
...
... requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY use the Content-Location URI ...
... Content-Location URI if the desire is to
identify the source of that particular entity.
A cache ...
... 23], is
an MD5 digest of the entity-body for the purpose of providing an
end-to-end message integrity check ...
... end-to-end message integrity check (MIC) of the entity-body. (Note: a
MIC is good for detecting accidental modification of the entity ...
... entity-body. (Note: a
MIC is good for detecting accidental modification of the entity-body
in transit, but is not proof against malicious attacks.)
...
... header field may be generated by an origin server to
function as an integrity check of the entity-body. Only origin
servers may generate the Content-MD5 header field ...
... gateways MUST NOT generate it, as this would defeat its value as an
end-to-end integrity check. Any recipient of the entity-body,
including gateways and proxies ...
... proxies, MAY check that the digest value in
this header field matches that of the entity-body as received.
The MD5 digest ...