5

This is related to: How should I implement a COUNT verb in my RESTful web service? , Paging in a Rest Collection and Using the HTTP Range Header with a range specifier other than bytes?

Actually I think the -1 rated anwser here is correct https://stackoverflow.com/a/1434701/1237617

Generally anwsers say that you can use custom units citing the sec 3.12

  range-unit       = bytes-unit | other-range-unit
  bytes-unit       = "bytes"
  other-range-unit = token

However when you read the HTTP spec please notice the production rules are thus:

   Content-Range = "Content-Range" ":" content-range-spec
   content-range-spec      = byte-content-range-spec
   byte-content-range-spec = bytes-unit SP
                             byte-range-resp-spec "/"
                             ( instance-length | "*" )

The header spec only references bytes-unit from sec 3.12, not range-units, so I think that actually it's against the spec to use custom units here.

Am I missing something or is the popular anwser wrong?

EDIT: Since this probbably isn't clear, the gist of my question is: rfc2616 sec14.16 only references bytes-unit. It never mentions range-unit, so range-unit production is not relevant for Content-Range, and thus only byte-units can be used.

I think this adresses my concerns best, although I needed some time to understand it (plus I wanted to make sure, that there is something wrong with the wording).

This reflects the fact that, apparently, the first set of grammar rules has been specifically made for parsing and the second one for producing HTTP requests

thanks to elgaton

Community
  • 1
  • 1
Jakub Bochenski
  • 3,113
  • 4
  • 33
  • 61

4 Answers4

3

If you read the HTTP/1.1 RFC, section 3.12, you will see that:

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.

So, the other-range-unit token has been introduced only to make servers more "liberal" when accepting. This reflects the fact that, apparently, the first set of grammar rules has been specifically made for parsing and the second one for producing HTTP requests, so that servers could accept even invalid requests (they will be simply ignored) and clients would use only the universally-accepted bytes unit.

Therefore, I personally recommend to:

  1. use only the bytes unit when acting as a client, and
  2. accept other units (discarding the Content-Range header if they are invalid) when acting as a server.
Alessandro Menti
  • 1,290
  • 20
  • 28
  • I've seen that - but I think my point still holds: the content-range production rules only reference byte-range. I dont see how the range-unit production is relevant here - unless I can't read the spec properly? – Jakub Bochenski Feb 28 '12 at 12:50
  • The production is there only to remark the fact that servers should accept (and silently discard) even unknown units; in case the HTTP/1.1 specification is revised (that's the case, as @Julian Reschke pointed out) and a client supporting the new specs talks with a server supporting only the old one, the latter will be still able to parse and process the request without errors. (Remember that, in HTTP, the client sends the request immediately without checking first which protocol versions are supported by the server, so he has no means to know, unless a 505 error is returned). – Alessandro Menti Feb 28 '12 at 16:27
3

The spec, as being revised, allows custom range units. See HTTPbis Part 5, Section 2.

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • 1
    Thanks for the information, but I'm interedted in a solution for the current standard. – Jakub Bochenski Feb 28 '12 at 12:53
  • 1
    Jakub, what's the practical impact of the publication status of the new spec? – Julian Reschke Feb 28 '12 at 14:17
  • 1
    I'm not sure I understand your question. This spec is now a draft, and after (if) it's approved we can probbably expect practical adoption within a couple of years -- so? While this is a useful quideline my motivation was to check if I understand the current specification correctly. – Jakub Bochenski Feb 28 '12 at 14:40
  • 1
    Jakub, you can use custom ranges right now if you control both client and server. (Note that Microsoft has done this for ages in Exchange) – Julian Reschke Feb 28 '12 at 15:19
  • 1
    Thanks again Julian I'm also aware of the Dojo use in JsonRestStore - docs.dojocampus.org/dojox/data/JsonRestStore#id7. However, while I understand it might be an ommision/error, can you confirm that literal reading of the current spec forbids it? Or explain to me what I'm reading wrong? – Jakub Bochenski Feb 28 '12 at 15:28
  • 1
    Jakub, literal reading of 2616 just shows that the spec is incomplete. That's why we are fixing it. – Julian Reschke Feb 28 '12 at 17:13
1

This is a purely personal opinion, but I think it is fairly consistent with how other HTTP extensions (custom methods or headers) are used. Here is how I read it: Yes I can use custom range units and no, I shouldn't submit a bug report when it gets ignored when passing through firewalls, web proxies, and other intermediaries. I conform to the HTTP spec when I'm sending it and they conform to HTTP when they ignore it. WebDAV uses HTTP extensions correctly, IMO, but rarely works over the Internet for exactly this reason. As I said, a personal opinion only.

Ferenc Mihaly
  • 1,155
  • 10
  • 4
  • This is an interesting point - I expect this will break caching. I mean that it will not onlt "not work" but it will cache and serve the partial content as full resource incorrectly if the header is ignored? – Jakub Bochenski Feb 28 '12 at 20:56
  • 13.4 says "However, a cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses", although I'm not sure if ignoring the header counts as "not supporting" for the puprose of this passage. – Jakub Bochenski Mar 09 '12 at 09:39
0

Apparently it's OK to use custom units, because:

This reflects the fact that, apparently, the first set of grammar rules has been specifically made for parsing and the second one for producing HTTP requests

Jakub Bochenski
  • 3,113
  • 4
  • 33
  • 61