Minor edits to draft 04

Except for the one for 14.10 (Connection, which contains several errors)
these are optional, but would result in a better document.

====================
Section 4.1 should include a reference [9] after the mention of RFC 822
in the third paragraph.

Also, the last note of that section:

  Note: certain buggy HTTP/1.0 implementations and/or scripts
  generated extra CRLF's before/after a request.  To restate what is

should be

  Note: Certain buggy HTTP/1.0 client implementations generate an
  extra CRLF after a POST request.  To restate what is

since that is the only case known to exist.

====================
Section 4.4, list item 4:

> 4.   If the message uses the MIME "multipart/byteranges" Content-Type,
>   which is self-delimiting, then that defines the length. This Content-
>   Type MUST NOT be used unless the sender knows that the recipient can

should be

4.   If the message uses the media type "multipart/byteranges",
  which is self-delimiting, then that defines the length. This
  media type MUST NOT be used unless the sender knows that the recipient can


====================
Section 5.1.1, para after BNF:
 
>The list of methods acceptable by a plain resource can be specified in
>an Allow header field (section 14.7). The return code of the response
>always notifies the client whether a method is currently allowed on a
>resource, as which methods are allowed can change dynamically. ...
 
should be
 
 The list of methods allowed by a resource can be specified in 
 an Allow header field (section 14.7). The return code of the response
 always notifies the client whether a method is currently allowed on a
 resource, since the set of allowed methods can change dynamically. ...

====================
Section 5.1.2, last paragraph:

  Note: The "no rewrite" rule prevents the proxy from changing the
  meaning of the request when the origin server is improperly using a
  non-reserved URL character for a reserved purpose, since it is not
  feasible to fix all CGI scripts (or script authors) use URI syntax
  correctly.
 
  Implementers should be aware that some pre-HTTP/1.1 proxies have
  been known to rewrite the Request-URI.

should be

  Note: The "no rewrite" rule prevents the proxy from changing the
  meaning of the request when the origin server is improperly using a
  non-reserved URL character for a reserved purpose.  Implementers
  should be aware that some pre-HTTP/1.1 proxies have been known to
  rewrite the Request-URI.

====================
Section 8.1.1, first sentence, the last comma should be removed. ", and .."

====================
Section 8.1.4, last paragraph, first sentence

  It is suggested that clients which use persistent connections SHOULD
  limit the number of simultaneous connections that they maintain to a
  given server.

should be

  Clients that use persistent connections SHOULD
  limit the number of simultaneous connections they maintain to a
  given server.

====================
Section 8.2, second bullet

  .  An HTTP/1.1 (or later) client doing a PUT-like method SHOULD
     monitor the network connection for an error status while it is
     transmitting the request. If the client sees an error status, it
     SHOULD immediately cease transmitting the body. If the body is
     being sent using a "chunked" encoding, a zero length chunk is used
     to mark the end of the message. If the body was preceded by a
     Content-Length header, the client MUST close the connection.

should be

  .  An HTTP/1.1 (or later) client sending a message-body SHOULD
     monitor the network connection for an error status while it is
     transmitting the request. If the client sees an error status, it
     SHOULD immediately cease transmitting the body. If the body is
     being sent using a "chunked" encoding (section 3.6), a zero length
     chunk and empty footer MAY be used to prematurely mark the end of
     the message. If the body was preceded by a
     Content-Length header, the client MUST close the connection.

and then the last bullet in Section 8.2:

  .  MUST close the connection if it has not already completed sending
     the full request body including any encoding mechanism used to
     transmit the body.

should be just

  .  MUST close the connection if it has not completed sending
     the message.

====================
Section 12.2, first paragraph

  With agent-driven negotiation, selection of the best representation for
  a response is performed by the user agent after receiving an initial
  response from the origin server. Selection is based on a list of the
  available representations of the response included within the header
  fields (this specification reserves the keyword Alternates, to be
  defined in a separate specification [27]) or entity-body of the [...]

should be

  With agent-driven negotiation, selection of the best representation for
  a response is performed by the user agent after receiving an initial
  response from the origin server. Selection is based on a list of the
  available representations of the response included within the header
  fields (for example, Alternates, as described in appendix 19.6.2.1)
  or entity-body of the [...]

and the reference [27] is not needed (the RFC editor doesn't like
to reference "works in progress" in a proposed standard).

====================
Section 13, end of third paragraph

  "the protocol requires that transparency may be relaxed"

should be

  "the protocol requires that transparency be relaxed"

and there is no 13.1 (but there is 13.1.1 and 13.1.2).

====================
Section 13.1.1 can be simplified, in addition to Ben Laurie's corrections

> 13.1.1 Cache Correctness
>  
> If the cache can communicate with the origin-server, then a correct
> cache MUST respond to a request with a response that meets one of the
> following conditions:
>  
>   1. Its end-to-end headers (see section 13.4.1) and entity-body value
>      are equivalent to what the server would have returned for that
>      request if the resource had not been modified since the response
>      was cached, by revalidating the response with the origin server, if
>      is not fresh.
>   2. It is "fresh enough" (see section 13.2). In the default case, this
>      means it meets the least restrictive freshness requirement of the
>      client, server, and cache (see section 14.9); if the origin-server
>      so specifies, it is the freshness requirement of the origin-server
>      alone.
>   3.       It includes a warning if the freshness demand of the client or the
>      origin-server is violated (see section 13.1.5 and 14.45).
> and it is the most up-to-date response appropriate to the request the
> cache has (see section 13.2.5, 13.2.6, and 13.10).
>  
> If the cache can not communicate with the origin server, then a correct
> cache SHOULD respond as above if the response can be correctly served
> from the cache; if not it MUST return an error or warning indicating
> that there was a communication failure.

like so

  13.1.1 Cache Correctness

  A correct cache MUST respond to a request with the most up-to-date
  response held by the cache that is appropriate to the request
  (see sections 13.2.5, 13.2.6, and 13.10) which meets one of the
  following conditions:

    1. It has been checked for equivalence with what the origin server
       would have returned by revalidating the response with the origin
       server (section 13.3);

    2. It is "fresh enough" (see section 13.2). In the default case, this
       means it meets the least restrictive freshness requirement of the
       client, server, and cache (see section 14.9); if the origin server
       so specifies, it is the freshness requirement of the origin server
       alone.

    3. It includes a warning if the freshness demand of the client or the
       origin server is violated (see section 13.1.5 and 14.45).

    4. It is an appropriate 304 (not modified), 305 (proxy redirect),
       or error (4xx or 5xx) response message.
  
====================
Section 13.3.3, middle of the section

  An entity tag is strong unless it is explicitly tagged as weak.
  Section 14.20 gives the syntax for entity tags.

the reference is wrong -- it should point to section 3.11.

====================
Section 13.3.4, first bullet

  "SHOULD send a entity tag"

should be

  "SHOULD send an entity tag"

[actually, a good way to find these is to search for " a e" and " an m"]

====================
Section 13.5, the third and fourth paragraph should be one paragraph

====================
Section 14.9, I missed a typo in the second-to-last bullet

  .  Controls over cache revalidation and reload; these may only be
     imposed by an user-agent.

should be "a user agent".  You may want to search for "user-agent"
and "origin-server" and globally remove those pesky hyphens.

====================
Section 14.10 (Connection), third paragraph to end

  HTTP/1.1 proxies MUST parse the Connection header field and, for every
  connection-token in this field, remove a corresponding header field from
  the request before the request is forwarded. The use of a connection
  option is specified by the presence of a connection token in the
  Connection header field, not by the corresponding additional header
  field (which may not be present).

  When a client wishes to close a persistent connection it SHOULD send a
  close connection-token, :
 
       Connection: close


NEEDS to be

  HTTP/1.1 proxies MUST parse the Connection header field before a message
  is forwarded and, for each connection-token in this field, remove any
  header field(s) from the message with the same name as the connection-token.
  Connection options are signaled by the presence of a connection-token
  in the Connection header field, not by any corresponding additional
  header field(s), since the additional header field may not be sent if
  there are no parameters associated with that connection option.

  HTTP/1.1 defines the "close" connection option for the sender to signal
  that the connection will be closed after completion of the response.
  For example,
 
       Connection: close

  in either the request or the response header fields indicates that the
  connection should not be considered "persistent' (section 8.1) after
  the current request/response is complete.

  HTTP/1.1 applications that do not support persistent connections
  MUST include the "close" connection option in every message.

====================
Section 14.11 (Content-Base), second sentence

  described as Base in RFC 1808 , which is expected to be revised soon.

should be

  described as Base in RFC 1808, which is expected to be revised.

====================
Section 14.17 (Content-Range), middle of section

  The Content-Range header is sent with a partial entity-body to specify
  where in the full entity-body the partial body should be inserted. It
  also indicates the total size of the full entity-body.
 
       Content-Range = "Content-Range" ":" content-range-spec
 
these should be moved to the top of the section.

====================
Section 14.19 (Date), middle paragraph

  "MUST always"

should be just "MUST", and the second-to-last paragraph

>Although origin servers MUST send a Date field in every response, if a
>cache receives a response without a Date field, it SHOULD attach one
>with the cache's best estimate of the time at which the response was
>originally sent.
 
is redundant (the same is said just two paragraphs above it).

====================
Section 14.43 (Vary), third paragraph

  The header fields named by the Vary field value is known as the
  "selecting" request-headers.

should either be "The set of " or "are known as".

====================
Section 14.45 (Warning) has no introductory paragraph like all other fields.

  The Warning response-header field is used to carry additional
  information about the status of a response which may not be reflected
  by the response status code.  This information is typically, though
  not exclusively, used to warn about a possible lack of semantic
  transparency from caching operations.

instead of the current first paragraph.

====================
That's the last from me.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Friday, 7 June 1996 16:59:57 UTC