Support for `Content-Range` HTTP response header.
Dragomir-Ivanov opened this issue · comments
Use Content-Range HTTP response header, instead(or along side) X-Offset and X-Total.
It can also be implemented as a custom FormatList method, but still could be good if we comply to the standard way of doing things.
I don't think it's what the header is used for....
https://tools.ietf.org/html/rfc7233#section-4.2
I think it's used for browsers to concatenate a "raw" message (e.g. part of a very large JSON file, starting with [, but not ending/completing the JSON encoding`), and describing the range in raw bytes, rather than number of items.
Fair enough, however I see they use it for paginated requests here:
https://github.com/marmelab/FakeRest
And I want to add rest-layer backend to react-admin. In any case I can make custom FormatList so I guess we can close this issue.
I haven't read the HTTP spec in depth for 206 Partial Response, but on first glance, what FakeRest is doing, appears like an odd interpretation of it. It sounds to me like this are headers (and response codes) made to support video streaming and that sort of thing.
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206, note in particular:
The HTTP 206 Partial Content success status response code indicates that the request has succeeded and has the body contains the requested ranges of data, as described in the
Rangeheader of the request.
If several ranges are sent back, the Content-Type is set to
multipart/byterangesand each fragment covers one range, with Content-Range and Content-Type describing it.
@rs what's your view on using these headers?
On other hand HTTP 206 will be useful inPaginationDefaultLimit, where the client wasn't requested pagination, but it gets one any way.
For what it's worth, a related discussion on Stack Overflow:
Okay, lets keep what we have as now. Will close the issue now, but I guess we can return 206 when PaginationDefaultLimit kicks in.
If we did return a 206, I believe we would go against a MUST in the HTTP 1.1 spec:
From https://tools.ietf.org/html/rfc2616#section-10.2.7:
The server has fulfilled the partial GET request for the resource.
The request MUST have included a Range header field (section 14.35)
indicating the desired range, and MAY have included an If-Range
header field (section 14.27) to make the request conditional.
For inspiration to a different solution, GitHub uses the Link header for pagination:
This Link response header contains one or more Hypermedia link relations, some of which may require expansion as URI templates.
They seam to include next, last, first and prev links as needed.
Would rather keep what we have now, than using Link header.
Content-Range goes with range requests and is related to the actual bytes of the response. There is no guarantee that a range request will return valid json as the range can be arbitrary chosen by the client.
But unit can be other than bytes. Nothing prevents us to use items and supply returned range. I am not insisting on this, just curious how such important thing like resource pagination wasn't resolved in the standard, and forcing us to make custom headers like X-Total and X-Offset. Content-Range seemed like good candidate.
I’m not sure about that. I would assume that most http lib would interpret those headers and interfere.