-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Byte Range request beyond end of file #2991
Comments
@keniwhat I think this makes sense to make Vapor a little less strict. The only thing that would make me hesitant would be the RFC saying we MUST NOT accept invalid range requests. If you can link to the IETF RFC for range stuff in the PR where I'm sure it says we only SHOULD accept valid range requests that would be great |
As per this document (https://httpwg.org/specs/rfc7233.html), Section 2.1, the HTTP server should treat a range request beyond end-of-file as being upto end-of-file. Screenshot attached: |
@keniwhat even more reason to make Vapor more flexible then. Very happy to accept a PR 👍 |
@0xTim is this still a thing? If so I'd look into it :) |
@0xTim any update on this? |
I made the changes to the code and test as requested but it has not been merged. Let me know what you need from me to get this onto the main vapor/vapor project. |
@linus-hologram @keniwhat It looks like this is tracked in #2997? |
Describe the bug
A byte range request beyond end of file returns HTTP Status 400 (Bad Request).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
While Vapor behaviour is technically correct, other servers (apache, AWS - apache or nginx?) are more forgiving, returning the remaining bytes in the file. As a consequence of this historical leniency, HTTP client code exists (open source) that technically have this bug, but will work with other servers but not Vapor.
Can vapor be made more lenient in this respect?
That is, if a byte range request goes past end of file, just return bytes to end of file.
Environment
Additional context
I have patched vapor to affect this fix and it my client code works now with vapor.
The text was updated successfully, but these errors were encountered: