Various comments on pre-04

The dail-in service I normally use to send mail has conveniently
broken down just this weekend.  I have therefore batched several
comments on the pre-04 draft, which I originally planned to send in
separate messages, into one big message, and am trying to send it via
an different mail account.

Note that I am at this point unable to read any http-wg mail and any
private mail send to koen@win.tue.nl.

Messages are separated with =========.

Koen.

============

** Some wordsmithing remarks

3.1, the sentence at the start of the last paragraph:

 Proxy and gateway applications must be careful in protocol versions
                                                 ^^^
 different from that of the application.

looks like it is missing some part.  In the 03 draft, the sentence
was:

 Proxy and gateway applications MUST be careful in forwarding requests
 that are received in a format different from that of the application's
 native HTTP version.


8.2, enumerated list item 7:

  7. If client sees that the connection is closed prematurely, repeat
     from step 1 until the request is accepted, an error response is
     received, or the user becomes impatient.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think use of such language is strange in a spec.  I suggest
replacing `or the user becomes impatient'  with

     or until the user terminates the retry process.

13.1.2 first sentence:

 Whenever a cache returns a response that is neither firsthand nor
                                                     ^^^^^^^^^

'firsthand' should be 'first-hand'.

13.5 second paragraph third sentence:

 A cache can use the selected representation (the entity
 included with that particular response) for replying to subsequent
 requests on that resource only when the subsequent requests have the
 same or equivalent value for all header fields specified in the Vary
                    ^^^^^    
 response-header.

Shouldn't `value' be `values'?

13.11:

The paragraph starts with:

 The cache SHOULD use any new cacheable response to reply to 
 the current request.
 ^^^^^^^^^^^

without establishing a context. It is not clear to me what this
section is trying to say.  This looks like something that can be
trivially fixed, but I have not succeeded in finding a fix.


13.12:

I think the section becomes more clear if the second and third
paragraph are swapped.

14.6, last paragraph:

 If a cache receives a value larger than the largest positive integer
 it can represent, or if any of its age calculations overflows, it
 MUST transmit an Age header with a value of 2147483648
 (2^31). HTTP/1.1 caches MUST send an Age header in every response.
 Caches SHOULD use an arithmetic type of at least 31 bits of range.

I think the use of 2147483648 is very ugly.  I suggest the following
rewrite:

 If a cache receives a value larger than the largest positive integer
 it can represent, or if any of its age calculations overflows, it
 MUST transmit an Age header with the largest positive integer it can
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 represent. HTTP/1.1 caches MUST send an Age header in every response.
 ^^^^^^^^^
 Caches SHOULD use an arithmetic type of at least 31 bits of range.

14.20 second sentence:

 The entity tag may then be used for comparison with other
                    ^^^^
 entities from the same resource.

I suggest that the word `then' is removed.

==================

** 14.24 If-Modified-Since and 14.28 If-Unmodified-Since

These sections talk a lot about the `requested variant'.  I have two
problems with this:

a) it seems to imply that these headers are not useful for non-varying
resources

This is clearly contrary to the design of these headers and to current
practice.  I suggest that the text is rewritten, or that some comments
are added, to remove this implication.

b) it seems to imply that these headers are useful for validating
responses from varying resources

They _could_ be made useful for conditional requests on varying
resources, but the current rule of comparing to the modification date
of the selected variant is too simple-minded, as the selection
algorithm for the variants can change without the contents of the
variants being modified.

Complicated rules to make I-M-S do something useful in validations on
varying resources _could_ be made, but I see no point in opening this
can of worms.  Let's keep it simple.  

I suggest that we restrict the use of these headers as in the 03
draft, and state that

 - clients SHOULD use if-match and if-nomatch in in requests on
   varying resources

 - I-M-S and I-U-S MAY be ignored in requests on varying resources


=======================================================

** 14.26 If-None-Match

The section starts with:

 The If-None-Match request-header field is used with a method to make it
 conditional. A client that has one or more entities previously obtained
 from the resource can verify that none of those entities is current by
                                   ^^^^
 including a list of their associated entity tags in the If-None-Match
 header field.

I believe that `none' must be `one'.  If you get a 304 or 412 with an
ETag field, you only know that this particular entity is still current.

On a higher level, I think the above sentences are an extremely
confusing introduction to the use of this header.  The last paragraph
of the section:

 The purpose of this feature is to allow efficient updates of cached
 information with a minimum amount of transaction overhead.   It is also
 used, on updating requests, to prevent inadvertent modification of a
 resource which was not known to exist.

is an extremely clear introduction, and I suggest that this last
paragraph is moved to the top of the section.

Below the BNF is the text:

 If any of the entity tags match the entity tag of the entity that would
 have been returned in the response to a similar GET request on that
                                       ^^^^^^^^^^^^^^^^^^^^^
 resource, or if "*" is given and any current entity exists for that
 resource, then the server MUST NOT perform the requested method.

I find this `a similar GET request' unacceptably vague.  Two GET
requests which only differ in the Accept-Language header can easily be
called `similar'.  Without an exact definition of `similar GET', the
above text is not a good definition of the semantics of the header.

I suggest that the following definition of `similar GET request' is
added to the end of the paragraph:

  If the current request is not a GET request, a similar GET request
  is constructed by changing the request method into GET and deleting
  the conditional headers.  If the current request is a GET request, a
  similar GET request is constructed by deleting the conditional
  headers.

If there is time, I suggest that someone tries to restructure this
section into a part that covers GET/HEAD requests and a part that
covers all other requests.  I suspect this will make the section much
easier to read.

Most of the above comments also apply to section 14.25 (If-Match).

==================================

** 14.25 If-Match and 14.28 If-Unmodified-Since

Both these sections require that all methods MUST NOT be performed in
some cases.  

I think this is an unnecessarily strong requirement for the GET and
HEAD methods.  This requirement makes it harder to implement a minimal
HTTP/1.1 server (because you MUST be able to decode the I-U-S header
value as soon as you have GETtable resources which return
Last-Modified values) and could possibly block some optimizations in
general 1.1 servers.

I suggest that the text is changed to weaken the requirement into
SHOULD NOT for the GET and HEAD methods.

==========================================

** 8.2 Entity Transmission Requirements

This section defines very complicated requirements for transmitting
entities.  It is unclear to me what the gain of having all this
complexity is, even if everybody implements it correctly.

In particular, it seems to me that the 100 response mechanism is not
very useful if the request is done though one or more firewall or
caching proxies.  The proxy will just immediately respond with a 100
code, as per the requirement:

 Upon receiving a method subject to these requirements from an HTTP/1.1
 (or later) client, an HTTP/1.1 (or later) server MUST either immediately
                                                              ^^^^^^^^^^^
 respond with 100 (Continue) status and continue to read from the input
 stream, or respond with an error status.

If the flow of entity data were delayed until the origin server had
had the chance to respond with an error code to the request headers,
the 100 mechanism would be moderately useful, but this is not the
case.  In a proxy situation, any origin server error response will
only be received by the user agent when it is sending or has finished
sending the entity data.

Unless someone comes up with a convincing explanation of why this
100 response needs to be introduced, and how it improves on an
exponential backoff, I suggest we cut it from the HTTP/1.1 draft.  It
seems to me that cutting the 100 response would be a relatively
painless way to simplify the overly complex section 8.2.

Below is an first approximation to a simplified 8.2 which cuts the 100
response.

 8.2 Entity Transmission Requirements
 
 General requirements:

  .  HTTP/1.1 servers SHOULD maintain persistent connections and use
     TCP's flow control mechanisms to resolve temporary overloads,
     rather than terminating connections with the expectation that
     clients will retry. The latter technique can exacerbate network
     congestion.
  .  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.

 If the client sees the connection close before receiving any
 status from the server, it should use the following "binary
 exponential backoff" algorithm for any subsequent retry to be
 assured of eventually obtaining a reliable response:

  1.      Initiate a new connection to the server
  2.      Transmit the request-headers
  3.      Initialize a variable R to the estimated round-trip time to the
     server (e.g., based on the time it took to establish the
     connection), or to a constant value of 5 seconds if the round-trip
     time is not available.
  4.      Compute T = R * (2**N), where N is the number of previous retries
     of this request.
  5.      Wait either for an error response from the server, or for T seconds
     (whichever comes first)
  6.      If no error response is received, after T seconds transmit the body
     of the request.

=========================================

Koen.


-------------------------------------------------------------
	            DE  DIGITALE  STAD

Received on Saturday, 1 June 1996 08:17:18 UTC