is renderByteRanges doing the right thing?
In this function:
https://github.com/aristidb/http-types/blob/dda6874b98c39b8751d736080ff00a0c5e9d3456/Network/HTTP/Types/Header.hs#L166
The ByteRanges are render with an = sign. But according to section 14.16 of RFC2616:
https://www.ietf.org/rfc/rfc2616.txt
When rendering a byte range in a Content-Range header, there is no '=',
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 | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
| "*"
instance-length = 1*DIGIT
This is, of course, an = in the request. This seems like senseless inconsistency in the RFC itself.
Perhaps renderByteRanges is only intended to render the byte ranges in requests? And there should be a different function for rendering byte ranges in a response? Or I am misunderstanding something?
The more I think about this, the more I think I am abusing the ByteRanges type by trying to use it as part of a Response.
I currently need a number of hacks in order to set the Content-Range Response header:
setHeaderBS (original hContentRange) (C.pack "bytes " <> renderByteRange br <> (C.pack "/") <> (C.pack $ show contentLength)) $ ...
My feeling is that http-types currently has good support for the Request side of things but not so much for the Response side?
I wasn't aware that Content-Range uses space rather than =. Nice consistency, RFC 2616. :D I would be happy to accept a pull request that renders byte ranges with a space.
Better support for requests than for responses is probably not surprising given that http-types' earliest users were HTTP client libraries. But it's not deliberate.
parseByteRanges also cannot parse byte ranges with a space, so parsing a Content-Range header from a Response will fail.