mirror of
https://github.com/modoboa/modoboa.git
synced 2026-04-27 18:05:58 +03:00
[GH-ISSUE #458] Attachment download hangs with Nginx server #443
Labels
No labels
bug
bug
dependencies
design
documentation
duplicate
enhancement
enhancement
enhancement
feedback-needed
help-needed
help-needed
installer
invalid
looking-for-sponsors
modoboa-contacts
new-ui
new-ui
pr
pull-request
pyconfr
python
question
security
stale
webmail
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/modoboa-modoboa#443
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tonioo on GitHub (Dec 4, 2013).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/458
Originally assigned to: @tonioo on GitHub.
Originally created by Miroslav Abrahám on 2013-09-10T17:54:14Z
It always seems to happen that attachments are not downloaded fast enough but they hang for some time and either finish the download or timeout.
There are 2 workarounds for this:
Add "keepalive_timeout = 0;" to your Nginx config file
Comment out line 57 in modoboa/extensions/webmail/views.py as mentioned in issues #473 (may by more of a fix than a workaround)
The reason for this happening seems to be in Nginx that does not like the combination of gzip and keepalive (http://wiki.nginx.org/HttpGzipModule). The Content-Length (line 57) value of a file being sent to a browser is already gzipped while the file size is really bigger. Since they do not match, the download hangs until it reaches a default timeout set in the main nginx.conf file.
As already mentioned in #473, the downside of this is the fact that a user will not know what is the size of the file being downloaded and what is the current progress of the download.
@tonioo commented on GitHub (Dec 4, 2013):
Posted by Miroslav Abrahám on 2013-09-16T11:05:34Z
Or maybe even better then both of the previously mentioned options is the option no. 3: to determine a proper gzipped value
This thread could be helpful: http://stackoverflow.com/questions/957577/serving-gzipped-content-from-django
@tonioo commented on GitHub (Dec 4, 2013):
Posted by Antoine Nguyen on 2013-09-17T06:46:53Z
Let the django part compress attachments also means it will load the entire file into memory in order to gzip it... Nginx streams the encoding.
@tonioo commented on GitHub (Dec 4, 2013):
Posted by Miroslav Abrahám on 2013-09-17T07:08:03Z
Then maybe this Django snippet http://djangosnippets.org/snippets/365/ could be helpful as the file is not loaded into memory in order to discover it's length.
@tonioo commented on GitHub (Dec 4, 2013):
Posted by Antoine Nguyen on 2013-09-17T13:05:45Z
Applied in changeset commit:88d755431aa30f74e0c870ae1caea209adaa8780.