Nginx Upload Progress Module stops functioning once behind reverse-proxy

[Ben Johnson]

On 2/16/2015 3:52 PM, Francis Daly wrote:
> On Mon, Feb 16, 2015 at 02:55:51PM -0500, Ben Johnson wrote:
> 
> Hi there,
>

Hi, Francis, and thank you for taking the time to review my question and
respond. I value and appreciate your time.

>> I've recently compiled nginx-1.7.10 with a third-party upload-progress
>> tracking module, which is described at
>> http://wiki.nginx.org/HttpUploadProgressModule .
> 
> Read the first two paragraphs on that page...
> 
>> This module works perfectly well, until I attempt to put the entire
>> setup behind a reverse-proxy.
> 
> ...and draw a picture of what happens when a client sends a 1MB upload
> to nginx, and nginx sends it via proxy_pass to an upstream. That should
> show you why it fails.
>

Abashedly, as yet, I lack the familiarity with nginx (and
reverse-proxies, in general) to grasp the problem on a fundamental
level. I've tried to visualize the conundrum and I can see two potential
problems:

- The fact that this is really a three-tiered server setup: 1) the nginx
server running on port 443; 2) the nginx server running on port 1337; 3)
the PHP server running on the socket.

- The fact that in the config snippet I included, the server listening
on port 1337 is "feeding the file to itself". Intuitively (and
incorrectly, of course), it feels as though changing that second
proxy_pass to

proxy_pass https://127.0.0.1;

would solve the problem. But, as you suggested, it does not and cannot.

Any further explanation that you're willing to offer as to the
fundamental problem will not fall on deaf ears.

>> With this configuration, the upload progress reporting functions
>> correctly *only* if I access the reverse-proxy port directly, at
>> https://example.com:1337.
> 
> Yes.
> 
> That's what nginx does.
> 
> Why does there need to be an upload_progress module in the first place,
> instead of letting the upstream server take care of it?
> 

Because the upstream server (PHP) performs miserably by comparison when
handling massive file uploads (often in excess of 1GB), and doesn't
support the most important (to me) features of this nginx module,
coupled with the nginx Upload Module (
http://www.grid.net.ru/nginx/upload.en.html ).

In particular, I need the ability to track upload progress, server-side,
*and* support user-agents resuming uploads that fail for any reason.

> In this case, you have put your upload_progress module on your upstream
> server.
> 

That's fine. I was hoping to avoid it, but I have control over the
entire environment, so it's not a show-stopper.

I was hoping to implement the reverse-proxy configuration so that the
file-hungry virtual-host would have minimal potential to affect the
handful of other virtual-hosts running under the same nginx instance.

The idea was to "isolate" the virtual-host that employs these modules so
that it could be restarted, be replaced with a more recent version of
nginx, etc., with no real downtime risk to the upstream nginx instance.

Imagine a hosting environment in which the "top-most" (furthest
upstream) virtual-hosts are critical and should never drop offline for
any period of time, but wherein it's no big deal if the "child" nginx
instances go down for whatever reason. This was the topology I was
hoping to implement.

> Not going to work. At least until you can use an "unbuffered
> upload". Which is not in current nginx. (But is in other things.)
> 
> 	f
> 

I would rather push this functionality upstream and consolidate all
virtual-hosts, incurring whatever risk of downtime is introduced as a
result, than replace nginx with another piece of software.

Thanks again for assuring me that this simply won't work as-is and that
the best and only course of action is to move the virtual-host in
question upstream.

Eager to hear any additional thoughts or critiques you may have re: the
justification that I outlined. Maybe I'm "doing it wrong".

Respectfully,

-Ben