- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Wed, 03 Jul 1996 14:07:08 -0700
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: jg@w3.org
I hope these are self-explanatory -- they are all minor and mostly
due to revision errors. Since we need a new draft anyway ...
Whoever generates the text draft *must* edit it BY HAND before submitting
it as an Internet-Drafts in order to clean up the garbage formatting.
I am willing to do that this weekend (or Monday) if someone mails me
the raw text.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
==========================================================================
*** draft-ietf-http-v11-spec-05.txt Mon Jun 10 15:40:01 1996
--- typos.txt Wed Jul 3 13:42:09 1996
***************
*** 1525,1531 **** [3.12 Range Units, first para]
HTTP/1.1 allows a client to request that only part (a range of) the
response entity be included within the response. HTTP/1.1 uses range
! units in the Range (section 14.36), and Content-Range (section 14.17)
header fields. An entity may be broken down into subranges according to
various structural units.
--- 1525,1531 ----
HTTP/1.1 allows a client to request that only part (a range of) the
response entity be included within the response. HTTP/1.1 uses range
! units in the Range (section 14.36) and Content-Range (section 14.17)
header fields. An entity may be broken down into subranges according to
various structural units.
***************
*** 1630,1636 ****
4.3 Message Body
! The 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-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field (section
--- 1630,1636 ----
4.3 Message Body
! The 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-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field (section
***************
*** 1665,1671 ****
4.4 Message Length
! When a message-body is included with a message, the length of that body
is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message-body (such as
--- 1665,1671 ----
4.4 Message Length
! When a message-body is included with a message, the length of that body
is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message-body (such as
***************
*** 1687,1693 **** [4.4 Message Length]
4. If the message uses the media type "multipart/byteranges", which is
! self-delimiting, then that defines the length. This Content-Type MUST
NOT be used unless the sender knows that the recipient can parse it;
the presence in a request of a Range header with multiple byte-range
specifiers implies that the client can parse multipart/byteranges
--- 1687,1693 ----
4. If the message uses the media type "multipart/byteranges", which is
! self-delimiting, then that defines the length. This media type MUST
NOT be used unless the sender knows that the recipient can parse it;
the presence in a request of a Range header with multiple byte-range
specifiers implies that the client can parse multipart/byteranges
***************
*** 1890,1898 **** [5.1.2 Request-URI, last para]
Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using a
! non-reserved URL character for a reserved purpose, since it is not
! feasible to fix all CGI scripts (or script authors) use URI syntax
! correctly. Implementers should be aware that some pre-HTTP/1.1
proxies have been known to rewrite the Request-URI.
--- 1890,1897 ----
Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using a
! non-reserved URL character for a reserved purpose.
! Implementers should be aware that some pre-HTTP/1.1
proxies have been known to rewrite the Request-URI.
***************
*** 3524,3530 **** [11.1 Basic Authentication Scheme, last para]
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
! See section 15 for security considerations associated with Basic
authentication.
--- 3523,3529 ----
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
! See section 15 for security considerations associated with Basic
authentication.
***************
*** 3644,3650 **** [12.2 Agent-driven Negotiation, first para]
a response is performed by the user agent after receiving an initial
response from the origin server. Selection is based on a list of the
available representations of the response included within the header
! fields (this specification reserves the keyword Alternates, as described
in appendix 19.6.2.1) or entity-body of the initial response, with each
representation identified by its own URI. Selection from among the
representations may be performed automatically (if the user agent is
--- 3643,3649 ----
a response is performed by the user agent after receiving an initial
response from the origin server. Selection is based on a list of the
available representations of the response included within the 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. Selection from among the
representations may be performed automatically (if the user agent is
***************
*** 3786,3793 **** [13.1.1 Cache Correctness, leftover from prior change]
origin server is violated (see section 13.1.5 and 14.45).
4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or
error (4xx or 5xx) response message.
- and it is the most up-to-date response appropriate to the request the
- cache has (see section 13.2.5, 13.2.6, and 13.12).
If the cache can not communicate with the origin server, then a correct
cache SHOULD respond as above if the response can be correctly served
--- 3785,3790 ----
***************
*** 3807,3813 ****
13.1.2 Warnings
! Whenever a cache returns a response that is neither first-hand nor
"fresh enough" (in the sense of condition 2 in section 13.1.1), it must
attach a warning to that effect, using a Warning response-header. This
warning allows clients to take appropriate action.
--- 3804,3810 ----
13.1.2 Warnings
! Whenever a cache returns a response that is neither first-hand nor
"fresh enough" (in the sense of condition 2 in section 13.1.1), it must
attach a warning to that effect, using a Warning response-header. This
warning allows clients to take appropriate action.
***************
*** 4022,4029 **** [13.2.3 Age Calculations, as requested by Ben Laurie]
age of a response or cache entry.
In this discussion, we use the term "now" to mean "the current value of
! the clock at the host performing the calculation." All HTTP
! implementations, but especially origin servers and caches, should use
NTP [28] or some similar protocol to synchronize their clocks to a
globally accurate time standard.
--- 4019,4026 ----
age of a response or cache entry.
In this discussion, we use the term "now" to mean "the current value of
! the clock at the host performing the calculation." Internet hosts that
! use HTTP, particularly those hosting origin servers and caches, should use
NTP [28] or some similar protocol to synchronize their clocks to a
globally accurate time standard.
***************
*** 5186,5192 ****
14.5 Accept-Ranges
! The Accept-Ranges response header allows the server to indicate its
acceptance of range requests for a resource:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
--- 5183,5189 ----
14.5 Accept-Ranges
! The Accept-Ranges response-header field allows the server to indicate its
acceptance of range requests for a resource:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
***************
*** 5232,5238 **** [14.6 Age, last para]
If a cache receives a value larger than the largest positive integer it
can represent, or if any of its age calculations overflows, it MUST
transmit an Age header with a value of 2147483648 (2^31). HTTP/1.1
! caches MUST send an Age header in every response. Caches SHOULD use an
arithmetic type of at least 31 bits of range.
--- 5229,5236 ----
If a cache receives a value larger than the largest positive integer it
can represent, or if any of its age calculations overflows, it MUST
transmit an Age header with a value of 2147483648 (2^31). HTTP/1.1
! caches MUST send an Age header field in any response obtained from
! its own cache. Caches SHOULD use an
arithmetic type of at least 31 bits of range.
***************
*** 5380,5386 **** [14.9 Cache-Control]
. Modifications of the basic expiration mechanism; these may be
imposed by either the origin server or the user agent.
. Controls over cache revalidation and reload; these may only be
! imposed by an user agent.
. Control over transformation of entities.
. Extensions to the caching system.
--- 5378,5384 ----
. Modifications of the basic expiration mechanism; these may be
imposed by either the origin server or the user agent.
. Controls over cache revalidation and reload; these may only be
! imposed by a user agent.
. Control over transformation of entities.
. Extensions to the caching system.
***************
*** 5421,5427 ****
caches that have been configured to return stale responses to client
requests.
! Note: HTTP/1.0 caches will not recognize or obey this directive.
14.9.2 What May be Stored by Caches
--- 5419,5425 ----
caches that have been configured to return stale responses to client
requests.
! Note: Some HTTP/1.0 caches will not recognize or obey this directive.
14.9.2 What May be Stored by Caches
***************
*** 5668,5674 **** [14.9.5 No-Transform Directive]
Therefore, if a response includes the no-transform directive, an
intermediate cache or proxy MUST NOT change those headers that are
! listed in section 13.5.2as being subject to the no-transform directive.
This implies that the cache or proxy must not change any aspect of the
entity-body that is specified by these headers.
--- 5666,5672 ----
Therefore, if a response includes the no-transform directive, an
intermediate cache or proxy MUST NOT change those headers that are
! listed in section 13.5.2 as being subject to the no-transform directive.
This implies that the cache or proxy must not change any aspect of the
entity-body that is specified by these headers.
***************
*** 5767,5773 **** [14.11 Content-Base]
The Content-Base entity-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, which is expected to be revised soon.
Content-Base = "Content-Base" ":" absoluteURI
--- 5765,5771 ----
The Content-Base entity-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, which is expected to be revised.
Content-Base = "Content-Base" ":" absoluteURI
***************
*** 5931,5943 ****
14.16 Content-MD5
! The Content-MD5 entity-header field, as defined in RFC 1864 [23] is a
! MD5 digest of the entity-body, for the purpose of providing an end-to-
end message integrity check (MIC) of the entity-body. (Note: a MIC is
good for detecting accidental modification of the entity-body in
transit, but is not proof against malicious attacks.)
! ContentMD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
--- 5929,5941 ----
14.16 Content-MD5
! The Content-MD5 entity-header field, as defined in RFC 1864 [23], is a
! MD5 digest of the entity-body for the purpose of providing an end-to-
end message integrity check (MIC) of the entity-body. (Note: a MIC is
good for detecting accidental modification of the entity-body in
transit, but is not proof against malicious attacks.)
! Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
***************
*** 6001,6013 ****
14.17 Content-Range
When a server returns a partial response to a client, it must describe
both the extent of the range covered by the response, and the length of
the entire entity-body.
- The Content-Range header is sent with a partial entity-body to specify
- where in the full entity-body the partial body should be inserted. It
- also indicates the total size of the full entity-body.
Content-Range = "Content-Range" ":" content-range-spec
--- 5999,6012 ----
14.17 Content-Range
+ The Content-Range entity-header field is sent with a partial entity-body
+ to specify
+ where in the full entity-body the partial body should be inserted. It
+ also indicates the total size of the full entity-body.
When a server returns a partial response to a client, it must describe
both the extent of the range covered by the response, and the length of
the entire entity-body.
Content-Range = "Content-Range" ":" content-range-spec
***************
*** 6428,6434 **** [14.26 If-None-Match, second para]
is also used, on updating requests, to prevent inadvertent modification
of a resource which was not known to exist.
! As a special case, the value "*" matches any current entity of the
resource.
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
--- 6427,6433 ----
is also used, on updating requests, to prevent inadvertent modification
of a resource which was not known to exist.
! As a special case, the value "*" matches any current entity of the
resource.
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
***************
*** 6606,6612 ****
14.31 Max-Forwards
! The Max-Forwards general-header field may be used with the TRACE method
(section 14.31) to limit the number of proxies or gateways that can
forward the request to the next inbound server. This can be useful when
--- 6605,6611 ----
14.31 Max-Forwards
! The Max-Forwards request-header field may be used with the TRACE method
(section 14.31) to limit the number of proxies or gateways that can
forward the request to the next inbound server. This can be useful when
***************
*** 6869,6875 **** [14.36.2 Range Retrieval Requests, last para]
In some cases, it may be more appropriate to use the If-Range header
(see section 14.27) in addition to the Range header.
! If a proxy that supports byte ranges receives a Range request, forwards
the request to an inbound server, and receives an entire entity in
reply, it SHOULD only return the requested range to its client. It
SHOULD store the entire received response in its cache, if that is
--- 6868,6874 ----
In some cases, it may be more appropriate to use the If-Range header
(see section 14.27) in addition to the Range header.
! If a proxy that supports ranges receives a Range request, forwards
the request to an inbound server, and receives an entire entity in
reply, it SHOULD only return the requested range to its client. It
SHOULD store the entire received response in its cache, if that is
***************
*** 7896,7905 **** [References]
- [27] Work in progress on content negotiation of the HTTP working
- group.
-
-
[28] Mills, D, "Network Time Protocol, Version 3.", Specification,
Implementation and Analysis RFC 1305, University of Delaware, March,
--- 7895,7900 ----
***************
end-of-diff
Received on Wednesday, 3 July 1996 14:30:48 UTC