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

comments on draft-ietf-http-v11-spec-rev-03

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Thu, 26 Mar 1998 13:29:29 -0500 (EST)
Message-Id: <199803261829.NAA23034@aleatory.research.bell-labs.com>
To: jg@w3.org
Cc: http-wg@cuckoo.hpl.hp.com
Here are my comments on draft-ietf-http-v11-spec-rev-03.

Dave Kristol
==============

Substantive:

10.2.5 204 No Content

The server has fulfilled the request but does not need to return an
entity-body, and may want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the requested
variant.

    Is it appropriate to sent an Etag with 204?  (I think so.)  If so,
    then, because Etag is no longer an entity header, the wording needs
    to be amended.

14.26 If-None-Match
    I was disappointed that the pseudo-code didn't make it.  OTOH,
    there are now disclaimers about mixing various conditional
    headers, which accomplishes the same thing.
    
    I would like to see stronger advice in 13.3.4 about what
    combinations of conditional headers a client can send reliably to a
    server (or which combinations it must not send).

Nits:

10.2.7 206 Partial Content
    .  Either a Content-Range header field (section 14.16) indicating the
                        ===== --> Courier  (In the .ps version, this is
					Roman.)
       range included with this response, or a multipart/byteranges
       Content-Type including Content-Range fields for each part. If a
       Content-Length header field is present in the response MUST match
       					 insert: its value --^
       the actual number of OCTETs transmitted in the message-body.

10.4.14 413 Request Entity Too Large

The server is refusing to process a request because the request entity
is larger than the server is willing or able to process . The server may
					      delete --^

11 Access Authentication

HTTP provides several optional challenge-response authentication
mechanisms which MAY be used by a server to challenge a client request
and by a client to provide authentication information. The general
framework for access authentication, and the specification of "basic"
					      insert: s --^

14.26 If-None-Match

The result of a request having both an If-None-Match header field and
either an If-Match or an If-Unmodified-Since header fields is undefined
					        delete --^
by this specification.

14.28 If-Unmodified-Since

The result of a request having both an If-Unmodified-Since header field
and either an If-None-Match or an If-Modified-Since header fields is
						       delete --^
undefined by this specification.

14.40 Trailer

The Trailer general field value indicates that the given set of header
fields are present in the trailer of a message encoded with chunked
				   change to: that has ====
transfer-coding.

19.6 Compatibility with Previous Versions

For most implementations of HTTP/1.0, each connection is established by
the client prior to the request and closed by the server after sending
the response. Some implementations implement the Keep-Alive version of
persistent connections described in section Error! Reference source not
					    ===========================
found..
======

    In the PostScript version this looks like "19.6.2.0".  It's obviously
    a dangling reference.

19.6.3.1 Significant Changes From the Proposed Standard Protocol

A new error code (416))was needed to indicate an error for a byte range
		      ^-- change to space
request that falls outside of the actual contents of a document.
(Section 10.4.17)
Received on Thursday, 26 March 1998 10:32:35 EST

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