- 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