Skip to content
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

Open
stepcut opened this issue Mar 17, 2016 · 3 comments
Open

is renderByteRanges doing the right thing? #64

stepcut opened this issue Mar 17, 2016 · 3 comments

Comments

@stepcut
Copy link

stepcut commented Mar 17, 2016

In this function:

renderByteRangesBuilder :: ByteRanges -> Blaze.Builder

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?

@stepcut
Copy link
Author

stepcut commented Mar 18, 2016

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?

@aristidb
Copy link
Owner

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.

@joeyh
Copy link

joeyh commented Apr 6, 2018

parseByteRanges also cannot parse byte ranges with a space, so parsing a Content-Range header from a Response will fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants