816302 - [socorro-dev] accept gzip-encoded HTTP multi-part form POST in Zeus or Apache

Status: RESOLVED DUPLICATE of bug 818682

(Infrastructure & Operations Graveyard :: WebOps: Other, task, P3)

Description

[Robert Helmer [:rhelmer]]

We'd like to test out receiving gzipped HTTP POSTs on crash-stats-dev.allizom.org

I am hoping that we can terminate it on the zeus as we do with SSL, since WSGI spec doesn't cover this case and most implementations seem to just read up to the provided Content-Length (which will be far too small in the case of a compressed file) - see http://stackoverflow.com/questions/1559416/apache-lags-when-responding-to-gzipped-requests and linked thread.

Comment 1

[Robert Helmer [:rhelmer]]

Just FYI, we *might* not need this - we went ahead and tried doing this with Apache, in the <Location /submit> in /etc/httpd/conf.d/crash-reports.mozilla.com.conf:
SetInputFilter DEFLATE

Then, kats was able to submit fine:
https://crash-stats-dev.allizom.org/report/index/3ac9e0f9-74a8-49df-bdcf-d10322121129

I think it'd still be more convenient to do this on the loadbalancer, and we'll need to make sure we don't run into any problems, but it does seem to work without modification to the code. It may be possible that our mod_wsgi handler (part of web.py) ignores the Content-Length and reads to the end of the input data (which it should per the spec).

This whole "Content-Length" issue is mentioned on http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#input also, FWIW. That probably explains it better than I am.

Comment 2

[Jake Maul [:jakem]]

That Apache solution seems a lot more likely... as far as we've been able to determine, Zeus only supports gzip compression on outbound traffic, not decompression on inbound POSTs. Thanks for finding it!

Comment 3

[Robert Helmer [:rhelmer]]

Going to handle this in Apache on the collectors instead, since Zeus does not seem to support it per comment 2. Thanks for looking into this!