cpython
cpython copied to clipboard
python
http.server does not support HTTP range requests
| BPO | 42643 |
|---|---|
| Nosy | @AraHaan, @sblondon, @DavidBord |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2020-12-15.02:24:06.143>
labels = ['type-feature', 'library', '3.9', '3.10']
title = 'http.server does not support HTTP range requests'
updated_at = <Date 2021-02-20.22:02:16.315>
user = 'https://github.com/AraHaan'
bugs.python.org fields:
activity = <Date 2021-02-20.22:02:16.315>
actor = 'DavidBord'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-12-15.02:24:06.143>
creator = 'Decorater'
dependencies = []
files = []
hgrepos = []
issue_num = 42643
keywords = ['patch']
message_count = 4.0
messages = ['383028', '383029', '383685', '387429']
nosy_count = 3.0
nosy_names = ['Decorater', 'sblondon', 'DavidBord']
pr_nums = ['24228']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue42643'
versions = ['Python 3.9', 'Python 3.10']
Linked PRs
- gh-118949
I have issues with range requests on http.server module (ran from python -m http.server command)
When requesting files to download from an program written in C (which uses range requests to update an progress bar) it ignores this and simply forces download of the entire thing at once) which in turn on my program makes the progress bar never update to display the progress of the download to the user.
https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#range.units
It is a part from HTTP/1.1, I think this would be something good to actually have to support partial requests (if they request an range in the header of their request), for directory listings (which can be used to download files from), it could be considered helpful it be able to request specific byte ranges inside of the files to download at a time to split up bandwidth to not overwhelm an file server.
It seems there are some packages that supports the range requests too:
https://github.com/danvk/RangeHTTPServer
Not sure if that supports python 3 or not. It could be used to make a patch for http.server though.
RangeHTTPServer seems to support python3: there is a try-except clause to manage the different import of SimpleHTTPServer: https://github.com/danvk/RangeHTTPServer/blob/master/RangeHTTPServer/main.py#L13
The code is under Apache 2.0 licence. I don't know if it can be integrated in codebase under the PSF licence.
Another question needs to be answered previously: does the maintainers want to add such feature to SimpleHTTPServer (which goal is to be very basic)? They could prefer to add a header refusing the Range header: Accept-Ranges: none
https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#header.accept-ranges
Hi,
I've just install RangeHTTPServer to try but it's don't work as expected. it don't care about port anymore
It don't use the new directory arguments from python3.
The Range HTTP is need for PXE KickStart install https://access.redhat.com/solutions/1231383
Redhat extract: If HTTP installation is used, confirm that the HTTP RANGE option is supported by the web server. Thehttpd package shipped by Red Hat supports it by default.
I will try to fork this project to made a new one too make it work with improuvement...
I created RangeHTTPServer many years ago but can't remember the last time I used it. I'd be very happy if this functionality made it into SimpleHTTPServer and I could archive the repo.
I started a python -m http.server today. It took me a day to debug the program and found out that it doesn't understand range requests. I can't believe this problem was raised 3 years ago and it still hasn't been resolved.
I'd also be very happy if range requests made it into the standard http.server. Use case: providing virtual images to HPE servers via iLO which requires range requests.
The previous implementation of PR #24228 had some serious problems (reading a whole file into memory), and the handling of Range Not Satisfiable was inconsistent with the specification, and hadn't progressed for some time.
So I've re-implemented PR #118949, solved the existing problems, and written more detailed test cases, hope someone can review it, thanks a lot!
@imba-tjd I'm sorry mentioning you, but this issue is a bit old. I saw you review the previous PR, could you please review my new PR?
