Re: Ranged PUT

> The description of the Content-Range entity-header (Section 14.17)
> requires four quantites: units, first-position, last-position, and
> entity-length.  My question concerns the requirement for
> entity-length.  When performing a ranged PUT, the client may not
> yet know the entire entity length.  Shouldn't entity length be
> optional in that case?
>
>Um, I wouldn't think so.  If the length isn't specified, how does the
>server know how much is coming?  How does it know how much space to
>reserve for it, either in memory or on disk?  If it doesn't know how
>much space is needed, how can it be certain it can handle the request?

The server is not *certain* it can handle _the entire stream of PUT
requests_. But the server always does know if it can handle each individual
PUT request. It appears to me that knowing the entire entity-length is an
optimization, not a necessity. If a ranged PUT request arrives that does
not contain an entity length, the server could get the current file length
and use that knowledge to extend the file if necessary. If the request
covers a range that the server is unable or unwilling to claim from the
file system - for example some file systems have problems with files longer
than 2*31, while other file systems allow 2*32, or 2**63, or 2**64 - then
the request can fail at that point.

>  I'm still trying to find a good way to PUT under HTTP/1.1 when (1)
>  I don't know the total length of the resource being created, and
>  (b) the resource may be written out of order.
>
>Why can't the client write it (to a temporary file, say) out of order
>first, get the size from the size of the file, and then send
>everything to the server?  More to the point, if the client can't do
>this, then how do you expect the server to solve the same problem?

As a matter of fact, our clients currently do write these files to their
local filesystems. The hope is that the network can operate in a similar
manner. Since the servers are under our control, we can implement the
necessary server behavior as above. We would like to not require the local
client to have the disk space necessary to cache the data, nor have the
client take the time to transfer the data to the server after after being
forced to write it to a local disk. It would be more time and space
efficient to send the data down the wire when it is being generated. It's
just that the client cannot tell at the start how much data there will be.

Of course, the protocol needs only one relaxed rule to allow such behavior.
In 14.17, change:

byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos
"/" entity-length

to:

byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos
["/" entity-length]


As is usually the case with such things, the issue is not the syntax, but
the semantics. But as I outlined above, I think the semantics are simple,
straightforward, and natural.

regards,
-jim

Received on Wednesday, 27 January 1999 11:59:09 UTC