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

HTTP content-range #875

Closed
PerilousApricot opened this issue Dec 12, 2018 · 10 comments
Closed

HTTP content-range #875

PerilousApricot opened this issue Dec 12, 2018 · 10 comments
Assignees

Comments

@PerilousApricot
Copy link
Contributor

Hello,

When accessing files over HTTPS, accessing subsets of the file with the Range header returns the following header for a 16kB read content-read: bytes 0-16384/16385.

According to the HTTP spec, however, the number after the slash (e.g. 16385) should be the length of the whole document, and not the length of the range that was just returned (ref [1] [2]).

I can trigger this on 4.8.5-1.osg34.el7

Cheers
Andrew

[1] https://tools.ietf.org/html/rfc7233#page-12
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range

@PerilousApricot
Copy link
Contributor Author

PerilousApricot commented Dec 12, 2018

BTW, Content-Length is correctly set to 16385, so I can't use that instead to work around the glitch

@bbockelm
Copy link
Contributor

The report looks correct to me.

To help us determine severity - how did you notice this problem? Is there a particular client that chokes on the incorrect response?

@PerilousApricot
Copy link
Contributor Author

Looks like this should be filesize instead of cnt on this line:

sprintf(buf, "%lld-%lld/%d", rwOps[0].bytestart, rwOps[0].byteend, cnt);

I'm working on a pure-python backend for uproot based on the HTTP api (so it doesn't have to have the xrootd C++ API), so there's no users yet. As a workaround, I can start with a HEAD call to get the file length.

@bbockelm
Copy link
Contributor

Could you send in a PR for this? Would be nice to squeeze this in prior to 4.9.0.

@PerilousApricot
Copy link
Contributor Author

Eyeballing it, this looks like a simple change: #876

@abh3
Copy link
Member

abh3 commented Apr 20, 2019

I believe this was fixed, was it not?

@PerilousApricot
Copy link
Contributor Author

PerilousApricot commented Apr 20, 2019 via email

@simonmichal
Copy link
Contributor

@PerilousApricot : your patch was included in 4.9.0, can we close this one?

@abh3
Copy link
Member

abh3 commented Feb 18, 2020

Fabrizzio, has this been fixed as I think it has?

@ffurano
Copy link
Contributor

ffurano commented Feb 18, 2020

Well, the fix seems correct to me, and I have not noticed any troubles since its commit

@ffurano ffurano closed this as completed Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants