Re: Range response with empty content

On 24/07/2015 7:16 a.m., A. Rothman wrote:
> Hi,
> 
> I'd like to suggest that RFC 7233 (or whatever will succeed it) should
> mention explicitly how a server should respond to a Range request when
> the requested resource has no content (e.g. empty file). Going through
> the RFC, this is what I found:


I agree.

> 
> One section says:
> 
> "If a valid byte-range-set includes at least one byte-range-spec with
> a first-byte-pos that is less than the current length of the
> representation, or at least one suffix-byte-range-spec with a
> non-zero suffix-length, then the byte-range-set is satisfiable.
> Otherwise, the byte-range-set is unsatisfiable."
> 
> so since first-byte-pos can never be less than 0, it will always be
> unsatisfiable, and should return 416.


For the record;

That is not Rothman' oppinion, but a SHOULD requirement from section 3.1
on returning 416 to all "unsatisfiable" ranges.


The quoted "first-byte-pos that is less than the current length of the
representation"

...  is from the end of section 2.1. After initial statements about how
"Byte offsets start at zero." and examples of how a client can request
range "bytes 0-0" and larger end position ranges all starting at 0.


206 definition says clearly its about transferring 1+ satifiable ranges.
Eliminating itself from relevance.

416 (as Rothman mentions below) says its about responding when all
requested first-byte-pos are *greater* than the available size.
Eliminating itself from relevance as well.


> 
> But the section on 416 says:
> 
> "The 416 (Range Not Satisfiable) status code indicates that none of
> the ranges in the request's Range header field (Section 3.1) overlap
> the current extent...
> For byte ranges, failing to overlap the current extent means that the
> first-byte-pos of all of the byte-range-spec values were greater than
> the current length of the selected representation."
> 
> 
> so a first-byte-pos of 0 is not greater than 0, and thus the 416 Not
> Satisfiable status does not apply here.
> 
> In addition to this contradiction, a 206 Partial Content response is
> not possible either since the required Content-Range can't specify an
> empty range (I think), plus, the response is not actually partial
> content.
> 
> For a suffix-byte-range-spec with a non-zero suffix length, it says:
> 
> "If the selected representation is shorter than the specified 
> suffix-length, the entire representation is used."
> 
> which will trivially include an empty representation if you're a
> mathematician, but in practice some implementations might try and
> calculate an actual numbered range and fall back into the same
> ambiguous 416 code path (this is only a guess). And you still can't
> return a 206 for it.

Well that was the intent of that suffix form IIRC.

Requesting "bytes -N". To find out what the file size is and get the
last few bytes from it (if any) in the process. As it locating the
checksum bytes at the end for CDN applications. This is actually a
satisfiable range when applied to 0-sized files.

A response with unsatisfiable-range spec is then correct for 206 on a
0-sized file, "Content-Range: bytes */0"

A Content-Length:0 header would also be warranted to signal there is no
actual payload bytes present.



> 
> As for a suffix-byte-range spec with a 0 suffix length (-0)... I
> don't know what happens there.

Suffix is zero so its unsatisfiable and falls into the 416 path with the
unsatisfiable-range response header mentioned above.


Some other things need considering:

Theres Section 4.4:
"
Note: Because servers are free to ignore Range, many
implementations will simply respond with the entire selected
representation in a 200 (OK) response.
"

And RFC 7231 status:

If the file actually does not exist, as opposed to existing with 0 size,
then 404 is correct because there would not normally have been a 200
response anyway.

If it was not actually a file, but some processing logics producing no
output. Then 204 is appropriate, since it signals that processing was
enacted. Range is no more relevant here than on 404.



> 
> Another consideration is the paragraph about allowing a client to limit
> the number of bytes requested without knowing the size of the selected
> representation. If a client always requests a range of e.g. 0-100000 for
> this stated purpose, it would likely expect to get normal 200 responses
> for anything under 100000 bytes (or possibly a 206?), and a truncated
> 206 for anything larger, but not suddenly have to deal with a 416 and
> interpret it as a successful empty content response, or worse, perform
> another round-trip to the server without the Range to handle this case.
> 

No round-trip is necessary. The "Content-Range: bytes */0" header
already contains explicit statement that the file is of 0-size which is
why the 416 happened (if at all).


> 
> In short, the RFC's handling of empty resources with regards to ranges
> appears to be self-contradictory or not well-specified or unintuitive
> (I'm not sure which).
> 
> My humble suggestion would be to specify that servers should return an
> empty 200 response if the resource content is empty, which I think would
> minimize complexity on client and server. I may be wrong. But at the
> very least, the current wording should be clarified to mention this case
> explicitly and how it should be dealt with, since it's quite confusing
> currently.
> 

It is noted at the end of section 4.4:
"
  Note: Because servers are free to ignore Range, many
      implementations will simply respond with the entire selected
      representation in a 200 (OK) response.
"

Athough 0-size is not called out. Because as mentioned above when the
right suffix-byte-range syntax is used the 206 does work. 204 or 404 may
also be applicable.

Amos

Received on Friday, 24 July 2015 18:03:18 UTC