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 _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
