I'm building an API, and trying to make it as RESTFul as possible.
To this end I've build a search 'controller', this allows you to query searchable params, and posting to it will Redirect (302) to a controller/resource that is the result of the search.
This other controller supports the "Range:" header to allow a client to request how much and where in the list of items it wants.
Reading the HTTP spec, it says that a server should only respond with a 206 partial content if the request contains a range header. Is it valid HTTP to send the range header along with a POST request?.
It is bad for me to respond with the first say 10 items, with a 206 even if a Range header wasn't supplied?. The 206 would give the client knowledge that it can ask for more items if it needs it.
a literal reading of http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html & http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7233.html indicates that RANGE is only applicable to GET requests.
I wonder why you don't use a GET request for your search, i'm guessing it would be idempotent so a GET would be more appropriate.
Also note that the only registered range unit is bytes, which probably wouldn't be too useful to you (see http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units ) you can of course have your own custom local units...but...
what i'm getting at is if you are already leaving the normal range spec to add your own unit, you can just as easily say that range applies for POST in your namespace.
personally i find it kind of weird to limit a response code to a specific request type...shouldn't a server be able to tell a client that it only is returning a range even it requested the whole thing?