-
-
Notifications
You must be signed in to change notification settings - Fork 372
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
Streaming response #16
Comments
ipkn#294 is a possible solution, although the Transfer-encoding would probably still be required here. |
Testing (running Firefox with GPRS throttling and downloading a 4.4MB png) seems to show that timeouts arent an issue for although maybe the encoding header should be added. |
It could be helpful however to stream responses larger than a certain size (say 1MB) automatically, the code for streaming is already there for static files, and can be extended to include all responses automatically, what do you think @mrozigor? |
If we already have a solution for this - why not? And maybe add some switch during compile time/configuration file to switch between current version and proposed one? |
Update: it seems chunked transfer is not exactly a part of the way we stream static files, but rather a different method altogether, according to MDN, chunked transfer ignores the content-size header, which could mean that the client will need to take data without knowing the size of that data, until a stop chunk is sent. In all honesty i don't know whether to send content-size and stream the response or use |
ipkn#169, ipkn#46, ipkn#37, ipkn#8
Seems to be the logical continuation of static file serving, because as far as I understand, the connection times out regardless of what's going on, so a large static file is extremely likely not to be sent fully.
The text was updated successfully, but these errors were encountered: