W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Next draft of HTTP/1.1 spec...

From: <jg@zorch.w3.org>
Date: Fri, 09 Aug 96 12:06:33 -0400
Message-Id: <9608091606.AA29392@zorch.w3.org>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:06 EDT