- From: Jacob Schroeder <jacob.schroeder@gmx.de>
- Date: Tue, 9 Feb 1999 13:27:44 -0500 (EST)
- To: www-lib@w3.org
On Wed, Jan 27, 1999 at 11:55:54AM -0500, Jim_Ravan@avid.com wrote: > > > > 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? > > > > > 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. a) whole document of unknown length (no subrange): chunked transfer coding b) see below > > > >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? > > > 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] The actual draft (rev 6) of HTTP/1.1 offers first "-" last "/" "*" for this case (sect. 14.16, Content-Range). The only problem is, that they are talking about "responses" in that context. I dont know, whether this is intended or not. Since you have to know the values for first and last, you know the size of the entity and you can add the required Content-Length: <last-first+1> header. Yours, Jacob
Received on Tuesday, 9 February 1999 14:02:14 UTC