RFC7233 - byte range response with empty representation

[amichair]

Regarding byte ranges, an empty (zero-length) representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero.

I would like to see an update to the RFC which explicitly resolve this self-contradiction in whatever way seems appropriate. The following is one suggestion, but there may be others:

I would like to suggest explicitly specifying that an empty 200 response should be returned in this case. It is the simplest solution to the current self-contradiction in the RFC, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information about the representation to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations (as opposed to more intricate solutions).

Perhaps the following can be added at the end of section 3.1:
"If all of the preconditions are true and the target representation
length is zero, the server SHOULD send a 200 (OK) response."

(someone in the discussion preferred this to be a MUST, but the SHOULD might be more in line with the previous sections and backward-compatibility if some implementations resolved this in some other way.)

I raised this in the mailing list a while back, and it got some discussion and support but did not get officially resolved. More recently I reported it as errata but it was rejected as not being an erratum and redirected here (I apologize - didn't realize issues moved to github, and still not sure what the distinction is :-) ), so here it is, raised again.

All suggestions and feedback are welcome.

[amichair]

So how do we get this fixed?

There was a discussion about it in the IETF mailing list, in which others confirmed the issue.
I opened an errata, but it was closed saying it's not an errata.
I was pointed here to open the issue, but got no response in 9 months so far.
What can I do to get a response or to help move this forward?
If the powers that be don't agree that the issue requires fixing, it would be nice to get such feedback explicitly and discuss it.
If this issue tracker is inactive and the issue should be posted somewhere else, I'd be happy to do it, just point me in the right direction.

[mnot]

We're not currently working on a revision to this document, so an official answer won't be forthcoming for a while. In the meantime, the best thing to do is to discuss it on list, taking the advice you get there.

See Roy's response in particular:
http://www.w3.org/mid/31A2BA09-FDC0-440F-B1DF-699BD8818D01@gbiv.com

[amichair]

Just looked this up to see if it's been forgotten... can I assume from the new labels that it's on someone's todo list and will be looked at eventually, even if it'll take a while longer? (btw the link your referenced actually contains another bug, so I'm referring to both, i.e. the whole discussion).

[amichair]

@royfielding Thanks for resolving the issues! Better late than never :-)

Indeed now there is no longer a self-contradition in the spec, but I'm curious, why did you change your mind since the discussion in the link above, where you seemed to prefer a 200 result for an empty resource (even suggesting a MUST), to the current fix which leans towards the 416 by defining it explicitly as unsatisfiable (with the option 200 downgraded to MAY), or at best makes it a tossup which option servers will implement? Did you have any specific pros/cons or use cases in mind? I guess I still prefer a 200 as the simpler and more straightforward solution :-)

[royfielding]

An implementation can choose to send 200. Making that a SHOULD or MUST would be a new normative requirement that isn't justifiable for interop.

[amichair]

ok. Thanks again!