W3C home > Mailing lists > Public > www-lib@w3.org > January to March 1999

Ranged PUT

From: <Jim_Ravan@avid.com>
Date: Tue, 26 Jan 1999 18:09:31 -0500
To: www-lib@w3.org
Message-ID: <85256705.007F3737.00@amm02.avid.com>

A question about HTTP/1.1 and ranged PUTs:

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?

For example, if I know the length of the total entity of foo.xml is 1K
bytes and I need to update bytes 64-127, I could send:

    PUT foo.xml HTTP/1.1
    Content-Length: 64
    Content-Range: bytes 64-127/1024

and be compliant with the current RFC. On the other hand, if I were in the
process of *creating* foo.xml and I had no idea how long it might end up
being, shouldn't I be able to send:

    PUT foo.xml HTTP/1.1
    Content-Length: 64
    Content-Range: bytes 64-127

or something to that effect? According to the current RFC, I cannot do this
and remain compliant. It is pretty clear that the authors of the RFC
considered the problem since the last sentence of the first paragraph of
the description of the PUT request (Section 9.6) states:

"The recipient of the entity  MUST NOT ignore any Content-* (e.g.
Content-Range) headers that it does not understand or implement and MUST
return a 501 (Not Implemented) response in such cases."

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. Has anyone else tackled this problem?

And, in case anybody asks, I couldn't find anything to indicate that the
WebDAV folks had addressed ranged PUTs. Did I miss something obvious?

Received on Tuesday, 26 January 1999 18:12:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:49 UTC