W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1998

Re: Comments (Part 3) on HTTP I-D Rev 05 (#'s 116, 134, 135, 138, 147 and 149)

From: Jim Gettys <jg@pa.dec.com>
Date: Mon, 16 Nov 1998 15:34:24 -0800
Message-Id: <9811162334.AA22110@pachyderm.pa.dec.com>
To: "Adams, Glenn" <gadams@spyglass.com>
Cc: "Getty, James" <jg@pa.dec.com>, "Masinter, Larry" <masinter@parc.xerox.com>, WG - HTTP <http-wg@hplb.hpl.hp.com>

I'm running out of time, and may not be able to review all of your (Glenn's)
points (submitted Friday, LONG after the end of IETF last call)
before having to start production of the draft for the ID draft
deadline.  

You (Glenn_ did ask in private mail that I look into points
116, 134, 135, 138, 147 and 149 in particular.

I'll look at your other points in this mail only if time permits. 

Again, thanks for all your efforts; I just wish they had been
sooner.
			- Jim



> 116. Section 14.16, pg. 111, 5th para., has 'A response with status
> code 206 (Partial Content) MUST NOT include a Content-Range field with
> a content-range-spec of "*"'. It isn't clear how to interpret this
> since it is not possible for the value of content-range-spec to be
> merely "*".  Perhaps this means 'with a content-range-spec which uses
> "*" as the instance-length'? If this is the case, then perhaps it
> would be better to change the definition of instance-length to:
> 
> instance-length = 1*DIGIT | "*"
> 
> And then say '... MUST NOT include a Content-Range field with an
> instance-length of "*"'.
> 

In out of band mail, Dave Krystol says:

"I believe this was meant:

   A server sending a response with status code 416 (Requested range not
   satisfiable) SHOULD include a Content-Range field with a byte-range-
   resp-spec of "*". The instance-length specifies the current length of
   the selected resource. A response with status code 206 (Partial
   Content) MUST NOT include a Content-Range field with a byte-range-resp-
   spec of "*".

This looks better to me as well.

> 134. Section 14.28, pg. 122, 1st para., why have "... the server
> SHOULD perform the requested operation as if the If-Unmodified-Since
> header were not present." while section 14.24, 2nd para., has "... the
> server MAY perform the requested method if the If-Match header field
> did not exist."? Suggest using consistent language in these sections
> "SHOULD/MAY", "operation/method", "were not present/did not exist".

The SHOULD/MAY difference is deliberate.  You need to understand the *
matching of If-Match.  I think things are ok as is.

> 
> 135. Section 14.28, pg. 122, 2nd para., should note the asymmetry in
> response codes with respect to "If-Modified-Since" (section 14.25).
> Here we have 412 (Precondition Failed) while in 14.25 we have 304 (Not
> Modified). This asymmetry is odd since If-Match and If-Not-Match both
> use 412.
> 

If-Modified-Since and If-Unmodified-Since are independent of Etags,
being date related.  If-Modified-Since has been the common cache validation
mechanism (rather, the only one before etages.)

Part of the asymmytry is due to If-Unmodified-Since is new in HTTP/1.1;
it seemed best if If-Unmodified-Since fit into the general precondition
failed framework.  We can't go back and change If-Modified-Since at this
date, though.  I don't think it is worth a note; if we noted every
piece of HTTP/1.0 strangeness, we'd be wading through too much extraneous
material.  "Ours is not to wonder why, ours is to do and die."

> 138. Section 14.35.2, pg. 127, 3rd para., 2nd bullet, has "It does not
> affect the 304 (Not Modified) response returned if the conditional is
> false." However, a 412 (Precondition Failed) response may apply as
> well.

No, Range is a modifier placed on other requests, specifying
which bytes are to be returned if an entity is transferred.  So it
is describing the case of when a Range header and conditional GET
is being performed; it is the case that you'll still get a 304 (Not Modified)
for a IF-Modified-Since, for example.


> 147. Section 14.39, pg. 130, item 3, if an implied "chunked" always
> gets qvalue of 1, then it will always win over lesser qvalues.
> Specifying "chunked;q=0" would permit overriding this default;
> however, the present syntax does not admit "chunked" (unless the
> syntax of t-codings is changed to:
> 
> t-codings = "trailers" | transfer-coding

I ran this one by Henrik.  He says:

"Nope, it's fine asis. Chunked can not be set to 0 - all the client can do
is to say whether it understands chunked with or without trailers. Other
encodings can use a value of q=1 (default) to be just as good as chunked.

Basically, the q-values are used as binary values. Understanding deflate
with -.65 doesn't make a lot of sense to me."

> 
> 149. Section 14.40, pg. 130, 4th para., has "A server MUST NOT include
> any header fields unless ...". I believe this should read "A server
> MUST NOT include any header fields in the trailer of a message unless
> ...".


Henrik points out that your complaint is due to an editorial mistake
I made in the last draft; the entire sentence was meant to be struck.  See:
http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q3/0135.html
for details.  It is mistakes like these that make me reluctant to
do more than absolutely necessary at this point.

So I'll fix it this time around.


				- Jim
Received on Monday, 16 November 1998 23:34:54 EST

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