On Tue, Feb 19, 2019, at 7:32 AM, Derek Lambert wrote:

I’m having an issue downloading attachments from HyperKitty. The download begins as expected, but never progresses. Eventually it times out. I imagine the browser is expecting data matching the content-length header, but never receives it.

Inspecting the contents of the download file reveals (address varies):

I’ve been able to work around the issue with the following patch:

--- env/lib/python3.7/site-packages/hyperkitty/models/email.py.orig 2018-12-06 21:38:39.544448735 +0000 +++ env/lib/python3.7/site-packages/hyperkitty/models/email.py 2018-12-06 23:01:39.923239421 +0000 @@ -309,7 +309,7 @@ def get_content(self): folder = self._get_folder() if folder is None: - return self.content + return self.content.tobytes() filepath = os.path.join(folder, str(self.counter)) if not os.path.exists(filepath): logger.error("Could not find local attachment %s for email %s",

I haven't been able to replicate the issue with the HyperKitty tests, presumably the issue is somewhere in the Django <-> uwsgi <-> nginx stack.

My configs are based on mailman-suite and maxking/docker-mailman. I've tried stripping out all the performance tweaks from my uwsgi and nginx configs, but no change.

Versions: HyperKitty 1.2.1 Postorius 1.2.3 Django 2.1.7 nginx 1.14.1 uwsgi 2.0.18 Python 3.7.2

Has anyone come across this before?

I am not sure if this is exactly a bug in Hyperkitty. I am not able to replicate this with a extremely complicated test: Downloading a signature file in an email on lists.mailman3.org. It runs on gunicorn + Django 2.1.5 ( I think) and latest Git heads of respective projects. Is this a recurring or one time thing that you observed? It would be great if we could you could capture the HTTP Headers with and without the patch you sent above to help debug why does `.tobytes()` lets you download. -- thanks, Abhilash Raj (maxking)

I modified my container to use Alpine 3.9 with Python 3.6 instead of Fedora 29 with Python 3.7. Still seeing the same issue, so it's not the distro or python. Thinking it must be something in one of my configs. Derek Lambert On 2/20/19, 3:00 PM, "Derek Lambert" wrote: *** PLEASE NOTE: This email transmission was sent using a CDW address but originated from an e-mail system that is neither controlled nor managed by CDW and its affiliates. Please use extreme caution when opening or responding to this email message.*** This happens with all attachments, regardless of file type. I've rebuilt my containers numerous times and have tried running them on different hosts. uwsgi does log it's only generating 26 bytes for attachment requests. Example: uwsgi: [pid: 15|app: 0|req: 3/20] 192.168.253.1 () {48 vars in 2110 bytes} [Wed Feb 20 20:18:35 2019] GET /hyperkitty/list/test-list@domain.com/message/XWTEPEKLG5DNHW4M223RH3ULQ3ZMNOKK/attachment/3/attachment.htm => generated 26 bytes in 36 msecs (HTTP/1.1 200) 13 headers in 649 bytes (1 switches on core 1) It doesn't appear it's a header issue, they're identical (except for the dates) with and without the patch. I can provide them if you'd like. I assume it's not an issue with HyperKitty since no one else has reported it. Was hoping someone had encountered this when running with uwsgi. Google was no help. Derek Lambert On 2/19/19, 5:21 PM, "Abhilash Raj" wrote: On Tue, Feb 19, 2019, at 7:32 AM, Derek Lambert wrote: > I’m having an issue downloading attachments from HyperKitty. The > download begins as expected, but never progresses. Eventually it times > out. I imagine the browser is expecting data matching the > content-length header, but never receives it. > > Inspecting the contents of the download file reveals (address varies): > > > > I’ve been able to work around the issue with the following patch: > > --- > env/lib/python3.7/site-packages/hyperkitty/models/email.py.orig 2018-12-06 21:38:39.544448735 +0000 > +++ > env/lib/python3.7/site-packages/hyperkitty/models/email.py 2018-12-06 > 23:01:39.923239421 +0000 > @@ -309,7 +309,7 @@ > def get_content(self): > folder = self._get_folder() > if folder is None: > - return self.content > + return self.content.tobytes() > filepath = os.path.join(folder, str(self.counter)) > if not os.path.exists(filepath): > logger.error("Could not find local attachment %s for email > %s", > > I haven't been able to replicate the issue with the HyperKitty tests, > presumably the issue is somewhere in the Django <-> uwsgi <-> nginx > stack. > > My configs are based on mailman-suite and maxking/docker-mailman. I've > tried stripping out all the performance tweaks from my uwsgi and nginx > configs, but no change. > > Versions: > HyperKitty 1.2.1 > Postorius 1.2.3 > Django 2.1.7 > nginx 1.14.1 > uwsgi 2.0.18 > Python 3.7.2 > > Has anyone come across this before? I am not sure if this is exactly a bug in Hyperkitty. I am not able to replicate this with a extremely complicated test: Downloading a signature file in an email on lists.mailman3.org. It runs on gunicorn + Django 2.1.5 ( I think) and latest Git heads of respective projects. Is this a recurring or one time thing that you observed? It would be great if we could you could capture the HTTP Headers with and without the patch you sent above to help debug why does `.tobytes()` lets you download. -- thanks, Abhilash Raj (maxking) _______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.mailman3.org_mailman3_lists_mailman-2Dusers.mailman3.org_&d=DwIGaQ&c=PzM68gSF_5r1R7BCE75oeA&r=GgD_LHpJpzqCgYl9euxHhlqYAOmF-LRf0L_q26FThVM&m=6lFbMwKnDzvRFwrPNL_OluTItjPTVXOnZmFuzLsx-rs&s=eUrR0gsTL0qXQZo06dWexZ_GuONEMyYpqT3l_TnlJqs&e=