Re: Semantics of Content-Range in the PUT method

    I have a question about the intended operation of the Content-Range
    range header in the PUT method. In section 14.17 the format is
    given as:

    Content-Range: bytes first_byte-last_byte/length

    Now, I assume that the indication of the first and last is where in
    the specified entity, the new data should be stored. But, in this
    case, what does the length indicate?  Generally, it means the total
    length of the requested entity. But in this case, is it the length
    of the entity before the update is applied or after? Furthermore,
    how can the client reliably know the length of the target entity?
    The client can get it with a HEAD method but it can't guarantee
    that the length won't have changed by the time the PUT method is
    processed. It seems to me that this field can no be reliably used
    so perhaps the server is just supposed to ignore it.

Actually, HTTP/1.1 includes a mechanism to solve this kind of
problem.  You *can* guarantee that the length hasn't changed
if you can make the (stronger) guarantee that the resource itself
hasn't changed, and this may be done using:

	If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

(see section 14.25).  In fact, we wrote:
    This behavior [i.e., what section 14.25 specifies] is most useful
    when the client wants to prevent an updating method, such as PUT,
    from modifying a resource that has changed since the client last
    retrieved it.

You could probably also use "If-Unmodified-Since" (section 14.28)
but I wouldn't rely on this, since the timestamp resolution is
only 1 second.   

    In addition, if the insert position is given such that first_byte
    is beyond the current end of file for the entity, what should the
    server do? Is this an error or should the server simply append to
    the end of th file or should the server seek to the given first
    position and before writing. In this last case, there may be a
    large chunk of undefined data in the file which I guess would just
    be NULLs.

I don't think we ever got around to specifying this, which means
(I guess) that this is server-dependent.  Maybe if someone thinks
the specification should be more, um, specific about this, then
you should write up an Internet-Draft on the topic.  Real Soon Now.

    I tried experimenting with the latest Jigsaw server to see what it
    does and found that it simply ignore the Content-Range in the PUT
    method (which is wrong according to sec. 9.6). So exactly what
    should be happening in this case?

Note that a server identifying itself as HTTP/1.1 is also expected
to obey the specification in section 14.25 of If-Match, in that
if the entity tags do not match, "the server MUST NOT perform the
requested method"; this is not optional! (and similarly for
If-Unmodified-Since).

-Jeff

Received on Monday, 27 January 1997 18:54:47 UTC