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
Can't serve html video #410
Comments
I think that this problem might be specific to serving media to iOS devices. I encountered it with trying to serve mp3 files to my iPhone. This stack overflow question has an answer that claims iOS likes to request particular Ranges of files. WebOb's FileApp seems to support Range: headers, with its app_iter_range() method. I haven't tried it yet, might do later today. I captured the HTTP headers that iOS sent me, and they did include Range.
In tcpdump, I saw that the web server sends the client a lot of data, and then eventually the iPhone sends back a lot of RST connection reset packets. I'm guessing that once the TCP data is handed off to the application, it resets the connection. |
I don't disagree with your analysis of the sequence of requests, by my bug report was tested (it failed) on Chrome and Firefox on Linux and Windows |
No idea about ios |
Ah, ok. I guess that I agree, I got a broken pipe with Chrome, but not with cURL. |
This comment has been minimized.
This comment has been minimized.
Is this still an issue with others? Ran into this last night will investigate |
It seems the issue described here was that Werkzeug didn't support 206 range responses. That was addressed in #977 in September 2016. #1704 pointed out that there was an inconsistency with the RFC for range requests for an entire file. That's pretty much the only explanation I can think of that may be continuing to cause issues. Given that there's been no activity on this and no reproducible examples, I'm going to consider this closed by #1711. If you're still having an issue after that's released, please open a new issue with a reproducible example. |
As described here
pallets/flask#712
The text was updated successfully, but these errors were encountered: