Various comments on pre-04

>
>============
>
>** 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.
>
You're right; broken sentence.  The old one isn't much better.
The new one says:

"Proxy and gateway applications must be careful when forwarding
messages in protocol versions different from that of the application."

>
>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.
>

Ok.

>13.1.2 first sentence:
>
> Whenever a cache returns a response that is neither firsthand nor
>                                                     ^^^^^^^^^
>
>'firsthand' should be 'first-hand'.
>

Ok.  fixed.

>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'?

Ok.

>
>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.
>
Editing mistake while removing  previous version.  The sentence now says:

"If a new cacheable response is received from a resource while any
existing responses for the same resource are cached, the cache SHOULD
use the new response to reply to the current request."

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

I suppose.

>
>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.
>

No.  We discussed this one at length in Palo Alto.  The
problem is that such a statement would likely to lead to
implementation problems between 64 and 32 bit systems (this
mail message is being composed on a 64 bit system.
It is very likely when, for example, and Alpha sent a PC a 64 bit
integer that the PC would get the wrong answer.

We tried to figure out a better rules than the fixed number 2147483648
and other rules had come up with that would be unlikely to end up with
such implementation traps, and failed.  The rules are simple, and works.
So we believe it should be left as is.

>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.
>

yes.

>==================
>
>** 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
>

The semantics are well defined as is; it makes perfect
sense as definined, I think.  There has been a fundamental
disconnect in many people's minds about content negotiation;
that is that there is such a thing as a varying resource,
distinct from a non-varying one.  

The subtlety is that there is but one thing; a resource.  At any given
time, there may or may not be more than one entity associated with it.

So saying that something should be used on varying or
non-varying resources doesn't really make sense, so making
such restrictions seems wrong to me.

Maybe I'm missing something here, and would not mind if
others looked at the definitions yet again.
>
>=======================================================
>
>** 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.
>

Good suggestion.  Done.

>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.

Too complicated for anyone to understand.

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
(without the If-None-Match header) on that resource, or if "*" is
given and any current entity exists for that resource, then the server
MUST NOT perform the requested method.

>
>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.

I don't have time to deal with this right now.

>
>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.

And complicate clients who would have to deal with either
getting an entity or not getting an entity in response.

As there are many more clients than servers, in the world
(and likely many more small specialized clients than servers),
this does not seem like the right tradeoff to me.

But I don't have time tonight to think this through in detail,
so feel free to raise it again.

BTW, you'll get much better feedback on mailing lists if you
split your messages up into independent, bitesized issues
so that people don't have to wade through your long messages.

>
>==========================================
>
>** 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.
>

Send this one to Roy and Jeff to stew over.  But I think the Continue
is needed to deal with some of the error conditions.  I don't have
the time tonight to figure it out from first principles.

Thanks for the comments.
				- Jim

Received on Sunday, 2 June 1996 21:11:33 UTC