- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 14 May 96 15:47:33 MDT
- To: Dave Kristol <dmk@allegra.att.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In the second paragraph, the phrase "... if the transport connection
was terminated in any unusual way" is too vague to be meaningful. I'm
unsure what it should say. (Jeff?) I think it should at least give
categories of events that qualify as "unusual".
How about
... if there is any uncertainty as to whether a terminated
transport connection was terminated without any error.
I can give examples of situations that might lead to uncertainty:
"connection reset by peer"
keepalive timeouts
closed because of an explicit timer expiration
any error condition (e.g., returned by the UNIX read() system call)
but I intended this to be vague because I don't have any experience
with non-BSD TCP stacks, and I've been told repeatedly by other people
on this list that such stacks sometimes work in mysterious ways.
On the other hand, the underlying rule is in conflict with our desire
to allow a cache to use and support range-retrieval operations to patch
up after failed transfers. (I think I may have already commented on
this issue to Jim Gettys, but I don't think he's had a chance to
address it in the spec.) For example, if the transfer of a 100KB
entity fails after 99KB, it would be nice to be able to keep those 99KB
in the cache, marked in some way as "partial content", and then do a
1KB range retrieval to finish the entity.
So probably the "MUST NOT store the response" in the previous
sentence should become "MUST NOT store the response unless
it is marked as a partial-content response." Note, however, that
the Content-Range header requires an indication of the total
length of the object, so it's not always possible to make use of
such a fragmentary response.
-Jeff
Received on Tuesday, 14 May 1996 15:57:39 UTC