-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is renderByteRanges doing the right thing? #64
Comments
The more I think about this, the more I think I am abusing the I currently need a number of hacks in order to set the
My feeling is that |
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. |
In this function:
http-types/Network/HTTP/Types/Header.hs
Line 166 in dda6874
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 '=',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 text was updated successfully, but these errors were encountered: