- From: <jg@zorch.w3.org>
- Date: Fri, 09 Aug 96 12:06:33 -0400
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
There have been a number of issues on the mailing list
in the last month that have accumulated and make it worth
another draft; they are all minor, and the area directors
(who have already seen this list) agree that none of these
changes are significant, and that issuing another draft will
therefore not delay such processing HTTP/1.1 by the IESG.
The IESG is happiest to approve things with zero changes
from last draft to RFC form, so issuing a draft 07 is the right
thing to do.
So that you can verify what changes I intend to make (and
let me know if Larry and I have missed anything in the mailing
list traffic that should be changed), what I currently intend
to change are all below, along with the names of people who
raised the issue. If I've missed something, and you let me know
by the end of Friday, I'll do what I can to deal with it.
I'll make an annoucement when I've submitted draft 07, probably
on Monday.
Below are two items:
1) an explanation of each change to Draft 06 I believe should be
reflected in the RFC. I intend submit an updated draft 07 by Monday,
August 12.
2) context diffs of these changes to the text version of Draft 06
itself.
As you can see by the explanations below, the changes are all minor.
- Jim Gettys
=====================
Explanation of changes:
Ross Patterson, Roy Fielding, Section 3.3.1
Added missing reference to RFC 850
Ronald Tschalaer, Section 8.2 Message Transmission Requirements
Added the words "to this HTTP/1.0 server" in the paragraph preceding
the binary exponential backoff algorithm, to clarify that this
algorithm only applies to HTTP/1.1 clients talking to HTTP/1.0
servers, which cannot otherwise reliably recieve a large entity
(a known problem with HTTP/1.0 today with Post operations).
This resolves the appearent conflict with language above this,
on retry after connections are aborted, for 1.1 clients talking to
1.1 servers.
Ross Patterson, Roy Fielding, Section 8.8.1 Purpose and Section 17 References
Separated references.
Anselm Baird - Section 13.1.4 Explicit User Agent Warnings
Example was incorrect; removed `Cache-Control:reload' example, as
there is no such directive in final HTTP/1.1
Ross Patterson, Paul Hethmod, Section 14.9 Cache-Control
BNF had minor error that would have required an '=' even if
delta-seconds not specified, so changed the line:
'| "max-stale" "=" [ delta-seconds ]'
to
'| "max-stale" [ "=" delta-seconds ]'
to correct this; this was my editing mistake in a previous draft
when applying changes circulated to the working group list, where
the changes were applied incorrectly in this area.
Also in section 14.9 there was an excess '|' in the BNF
so the obvious fix is to change:
cache-request-directive =
| "no-cache" [ "=" <"> 1#field-name <"> ]
To:
cache-request-directive =
"no-cache" [ "=" <"> 1#field-name <"> ]
Ross Patterson, 14.15 Content-Location
Typo of extra period in explanitory text.
Paul Hethmon, Section 14.17, Content-Range
The example was incorrect in Content-Range, lacking the
bytes-unit specifier.
Paul Hethmon, Section 14.25 If-Match
Example was incorrect; removed use of weak validators, since that is
not legal with If-Match.
Jeff Mogul, to clarify confusion on Vary - Section 14.43
Added sentence "Field-names listed in Vary headers are those of
request-headers."
Ross Patterson, 14.45 Warning
Typographical error, spec said ISO-8599-1 where it meant ISO-8859-1
(2 occurances in this section; the document elsewhere stated 8859
correctly).
Ross Patterson, Roy Fielding, 15.8 DNS Spoofing
Removed reference to DNSSEC work, as it isn't referenceable at this
time.
V. Padmanabhan, Jeff Mogul, Section 17 References
Reference 26 was not the best reference to the work.
Replaced with corrected reference.
Ross Patterson, Roy Fielding, 19.6.2.4
Added missing reference to HTML.
There was also a suggestion to alphebetize the references section, and
renumber. I do not think this is worth doing for Proposed, but I will
do so for Draft standard.
================
Context Diffs
================
*** draft-ietf-http-v11-spec-06.txt Tue Jul 9 14:41:17 1996
--- draft-ietf-http-v11-spec-07.txt Wed Aug 7 22:27:54 1996
***************
*** 1151,1157 ****
The first format is preferred as an Internet standard and represents a
fixed-length subset of that defined by RFC 1123 (an update to RFC 822).
The second format is in common use, but is based on the obsolete RFC
! 850 date format and lacks a four-digit year. HTTP/1.1 clients and
servers that parse the date value MUST accept all three formats (for
compatibility with HTTP/1.0), though they MUST only generate the RFC
1123 format for representing HTTP-date values in header fields.
--- 1151,1157 ----
The first format is preferred as an Internet standard and represents a
fixed-length subset of that defined by RFC 1123 (an update to RFC 822).
The second format is in common use, but is based on the obsolete RFC
! 850 [12] date format and lacks a four-digit year. HTTP/1.1 clients and
servers that parse the date value MUST accept all three formats (for
compatibility with HTTP/1.0), though they MUST only generate the RFC
1123 format for representing HTTP-date values in header fields.
***************
*** 2355,2361 ****
causing congestion on the Internet. The use of inline images and other
associated data often requires a client to make multiple requests of the
same server in a short amount of time. Analyses of these performance
! problems are available [30]; analysis and results from a prototype
implementation are in [26].
Persistent HTTP connections have a number of advantages:
--- 2355,2361 ----
causing congestion on the Internet. The use of inline images and other
associated data often requires a client to make multiple requests of the
same server in a short amount of time. Analyses of these performance
! problems are available [30][27]; analysis and results from a prototype
implementation are in [26].
Persistent HTTP connections have a number of advantages:
***************
*** 2578,2585 ****
older and will not use the 100 (Continue) response. If in this case the
client sees the connection close before receiving any status from the
server, the client SHOULD retry the request. If the client does retry
! the request, it should use the following "binary exponential backoff"
! algorithm to be assured of obtaining a reliable response:
1. Initiate a new connection to the server
--- 2578,2585 ----
older and will not use the 100 (Continue) response. If in this case the
client sees the connection close before receiving any status from the
server, the client SHOULD retry the request. If the client does retry
! the request to this HTTP/1.0 server, it should use the following "binary
! exponential backoff" algorithm to be assured of obtaining a reliable response:
1. Initiate a new connection to the server
***************
*** 4031,4037 ****
caching mechanisms. For example, the user agent may allow the user to
specify that cached entities (even explicitly stale ones) are never
validated. Or the user agent might habitually add "Cache-Control: max-
! stale=3600" or "Cache-Control: reload" to every request. The user should
have to explicitly request either non-transparent behavior, or behavior
that results in abnormally ineffective caching.
--- 4031,4037 ----
caching mechanisms. For example, the user agent may allow the user to
specify that cached entities (even explicitly stale ones) are never
validated. Or the user agent might habitually add "Cache-Control: max-
! stale=3600" to every request. The user should
have to explicitly request either non-transparent behavior, or behavior
that results in abnormally ineffective caching.
***************
*** 5502,5511 ****
| cache-response-directive
cache-request-directive =
! | "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
! | "max-stale" "=" [ delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
| cache-extension
--- 5502,5511 ----
| cache-response-directive
cache-request-directive =
! "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
! | "max-stale" [ "=" delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
| cache-extension
***************
*** 6078,6084 ****
Location also defines the base URL for the entity (see section 14.11).
The Content-Location value is not a replacement for the original
! 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 if the desire is to
identify the source of that particular entity.
--- 6078,6084 ----
Location also defines the base URL for the entity (see section 14.11).
The Content-Location value is not a replacement for the original
! 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 if the desire is to
identify the source of that particular entity.
***************
*** 6233,6239 ****
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
! Content-Range: 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
--- 6233,6239 ----
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
! Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
***************
*** 6573,6581 ****
resource has been changed without their knowledge. Examples:
If-Match: "xyzzy"
- If-Match: W/"xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
- If-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-Match: *
--- 6573,6579 ----
***************
*** 6612,6617 ****
--- 6610,6616 ----
+
Fielding, et al [Page 114]
***************
*** 7240,7246 ****
The Vary response-header field is used by a server to signal that the
response entity was selected from the available representations of the
! response using server-driven negotiation (section 12). The Vary field
value indicates either that the given set of header fields encompass the
dimensions over which the representation might vary, or that the
dimensions of variance are unspecified ("*") and thus may vary over any
--- 7239,7246 ----
The Vary response-header field is used by a server to signal that the
response entity was selected from the available representations of the
! response using server-driven negotiation (section 12). Field-names listed
! in Vary headers are those of request-headers. The Vary field
value indicates either that the given set of header fields encompass the
dimensions over which the representation might vary, or that the
dimensions of variance are unspecified ("*") and thus may vary over any
***************
*** 7249,7255 ****
Vary = "Vary" ":" ( "*" | 1#field-name )
-
Fielding, et al [Page 125]
--- 7249,7254 ----
***************
*** 7422,7428 ****
This decision may be based on any available knowledge, such as the
location of the cache or user, the Accept-Language field in a request,
the Content-Language field in a response, etc. The default language is
! English and the default character set is ISO-8599-1.
Fielding, et al [Page 128]
--- 7421,7427 ----
This decision may be based on any available knowledge, such as the
location of the cache or user, the Accept-Language field in a request,
the Content-Language field in a response, etc. The default language is
! English and the default character set is ISO-8859-1.
Fielding, et al [Page 128]
***************
*** 7430,7436 ****
INTERNET-DRAFT HTTP/1.1 Monday, July 08, 1996
! If a character set other than ISO-8599-1 is used, it MUST be encoded in
the warn-text using the method described in RFC 1522 [14].
Any server or cache may add Warning headers to a response. New Warning
--- 7429,7435 ----
INTERNET-DRAFT HTTP/1.1 Monday, July 08, 1996
! If a character set other than ISO-8859-1 is used, it MUST be encoded in
the warn-text using the method described in RFC 1522 [14].
Any server or cache may add Warning headers to a response. New Warning
***************
*** 7762,7771 ****
Clients using HTTP rely heavily on the Domain Name Service, and are thus
generally prone to security attacks based on the deliberate mis-
! association of IP addresses and DNS names. The deployment of DNSSEC
! should help this situation. In advance of this deployment, however,
! clients need to be cautious in assuming the continuing validity of an IP
! number/DNS name association.
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name association, rather than caching
--- 7761,7768 ----
Clients using HTTP rely heavily on the Domain Name Service, and are thus
generally prone to security attacks based on the deliberate mis-
! association of IP addresses and DNS names. Clients need to be cautious
! in assuming the continuing validity of an IP number/DNS name association.
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name association, rather than caching
***************
*** 7772,7777 ****
--- 7769,7776 ----
the result of previous host name lookups. Many platforms already can
cache host name lookups locally when appropriate, and they SHOULD be
+
+
Fielding, et al [Page 134]
***************
*** 8016,8029 ****
[25] P. Deutsch, "GZIP file format specification version 4.3." RFC
1952, Aladdin Enterprises, May, 1996.
! [26] Jeffrey C. Mogul. "The Case for Persistent-Connection HTTP". In
! Proc. SIGCOMM '95 Symposium on Communications Architectures and
! Protocols, pages 299-313. Cambridge, MA, August, 1995. A longer, more
! comprehensive version of this paper is available on line at
! <http://www.research.digital.com/wrl/techreports/abstracts/95.4.html>,
! Digital Equipment Corporation Western Research Laboratory Research
! Report 95/4, May, 1995.,
[28] Mills, D, "Network Time Protocol, Version 3.", Specification,
Implementation and Analysis RFC 1305, University of Delaware, March,
1992.
--- 8015,8030 ----
[25] P. Deutsch, "GZIP file format specification version 4.3." RFC
1952, Aladdin Enterprises, May, 1996.
! [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP
! Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995.
! Slightly revised version of paper in Proc. 2nd International WWW
! Conf. '94: Mosaic and the Web, Oct. 1994, which is available at
! http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html
+ [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP
+ Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>, USC/Information
+ Sciences Institute, June 1996
+
[28] Mills, D, "Network Time Protocol, Version 3.", Specification,
Implementation and Analysis RFC 1305, University of Delaware, March,
1992.
***************
*** 8032,8041 ****
1.3." RFC 1951, Aladdin Enterprises, May 1996.
[30] S. Spero. "Analysis of HTTP Performance Problems"
! <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>, Joe Touch,
! John Heidemann, and Katia Obraczka, "Analysis of HTTP Performance",
! <URL: http://www.isi.edu/lsam/ib/http-perf/>, USC/Information Sciences
! Institute, June 1996
[31] P. Deutsch, J-L. Gailly, "ZLIB Compressed Data Format Specification
version 3.3." RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996.
--- 8033,8039 ----
1.3." RFC 1951, Aladdin Enterprises, May 1996.
[30] S. Spero. "Analysis of HTTP Performance Problems"
! <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>,
[31] P. Deutsch, J-L. Gailly, "ZLIB Compressed Data Format Specification
version 3.3." RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996.
***************
*** 8055,8061 ****
-
Fielding, et al [Page 139]
--- 8053,8058 ----
***************
*** 8609,8615 ****
resource and some other resource. An entity MAY include multiple Link
values. Links at the metainformation level typically indicate
relationships like hierarchical structure and navigation paths. The Link
! field is semantically equivalent to the <LINK> element in HTML.
Link = "Link" ":" #("<" URI ">" *( ";" link-param )
--- 8606,8612 ----
resource and some other resource. An entity MAY include multiple Link
values. Links at the metainformation level typically indicate
relationships like hierarchical structure and navigation paths. The Link
! field is semantically equivalent to the <LINK> element in HTML.[5]
Link = "Link" ":" #("<" URI ">" *( ";" link-param )
------- End of Forwarded Message
Received on Friday, 9 August 1996 09:11:11 UTC