-
Notifications
You must be signed in to change notification settings - Fork 968
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
Support Negative Offset Range Requests on files.pythonhosted.org #12823
Comments
HTTP 501 indicates "Not Implemented" so that seems semantically correct. Range support is implemented by our CDN. I don't think we'd consider this a bug per se. I'm not sure how much (if any) control we have over changing this response for negative offsets, so I don't think this is likely to change. |
@ewdurbin |
@ewdurbin So I just ran into this as well, and..... I didn't change my code. So this worked a few weeks ago, but just stopped working? And I just checked some other package repos that use Fastly as their CDN, and they seem to be supporting it fine. It's only pythonhosted.org that's erroring out:
So this seems to be a recent, PyPI-specific regression? (Also as a side note, if there's an error here, it really should be 416 Range Not Satisfiable. The problem with 501 is that while it's not exactly wrong, it's a very generic "something is broken" error, so clients will usually give up, while code that's attempting range requests should have smart fallback logic for 416, like switching to requesting the whole file.) |
@njsmith Any idea when it last worked? On Dec 12th we enabled segmented caching at the request of Fastly, and I wonder if this is a side effect. |
Hmmm, yep. Confirmed by reverting Segmented Caching rollout on test-files.pythonhosted.org temporarily, which restored negative offset support: Before Segmented Caching:
After:
|
Fastly considered getting us moved over to Segmented Caching for files.pythonhosted.org urgent, so I don't see us reverting that. |
It's possible we can mention it to Fastly and it's something they might be able to implement on their end, but even if they were, no idea what time frame that would be. |
The (very confusing) syntax for range headers is We probably should send Fastly a bug report about this? I feel like CDN companies generally like to know when their HTTP implementation has a bug, even if it's not a show-stopper :-). BTW, the reason this matters is because it's useful for wheel METADATA fetches, like pip does here: https://github.com/pypa/pip/blob/main/src/pip/_internal/network/lazy_wheel.py (See also: gtsystem/python-remotezip#15) |
Support request has been submitted to Fastly. |
Fastly support confirms that Segmented Caching does not support such negative offsets. In addition they offered responses regarding suggested HTTP status codes for the response:
|
Seems our only recourse would be to write custom VCL to handle the requests, either
It seems the workaround making two requests ( |
I'm trying to understand the use case here: is it just to retrieve metadata? Would working towards implementing PEP 658 be a better use of our time? |
My engineer-brain insists that I point out: this is a weird way to describe an RFC-standard request that Fastly themselves support in their normal mode :-) Cf. RFC 7233 page 5:
yes
yes |
I'm going to close this. I don't think there's anything we can do here to move this issue forward, and PEP 658 is rolling out now which is a better way to handle this anyways. |
To corroborate the above, while pip will already prefer PEP 658 metadata when available, pypa/pip#12208 will fall back to performing a HEAD request to extract the |
Describe the bug
While absolute range headers (e.g. bytes=0-64) work properly, negative values in a range header return a 501 not implemented error (with a nonstandard message stating "Unsupported client range", even though range requests are otherwise supported.)
Expected behavior
Negative values are supposed to return a content-range offset from the end of the fille to the end. I.e. bytes=-64 should give content-range={content-length - 64}-{content-length}.
To Reproduce
Any range request may illustrate this. Here's a curl command.
Returns:
Should return:
Additional context
If this is explicitly not implemented for some reason, please consider returning a 405 (Method Not Allowed) response instead, since 501 implies the request is not recognized.501 is appropriate. Ignore me on that (:
The text was updated successfully, but these errors were encountered: