Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Wrong URL for File Load/Download Buttons through NGINX Reverse Proxy Subfolder #1391
What were you doing?
Clicking the Load/Download buttons.
When NGINX is used as a reverse proxy, redirecting a subfolder like /octoprint to an octopi installation, the links provided by file load/download buttons are wrong.
This is posted when the reverse proxy is used to redirect a subfolder.
This posted when the reverse proxy is used with a root directory (ie. location "/"), or when the octopi server is used directly.
What did you expect to happen?
Actually Load/Download files.
What happened instead?
Nothing, due to wrong URL POST.
Branch & Commit or Version of OctoPrint
Version: 1.2.13 (master branch)
Printer model & used firmware incl. version
TazStiff, Marlin Firmware
Browser and Version of Browser, Operating System running Browser
Link to octoprint.log
Link to contents of terminal tab or serial.log
Screenshot(s) showing the problem:
Revelant portions of my NGINX configuration are as follows, based on the example at https://github.com/foosel/OctoPrint/wiki/Reverse-proxy-configuration-examples .
I have read the FAQ.
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).
If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-07-10 16:20) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.
Jun 26, 2016
At first I couldn't reproduce this at all. http nginx -> OctoPrint, http nginx -> http haproxy -> OctoPrint, https nginx -> OctoPrint, https nginx -> http haproxy -> OctoPrint, all worked flawlessly. Then I tried https nginx -> https haproxy -> OctoPrint and finally could reproduce.
The problem is actually two fold:
Problem number 1 I've solved in 0376bc4. Problem number 2 needs to be solved in the intermediary reverse proxy, by ensuring an
should do it.
Since only problem number 1 was actually an OctoPrint problem, I'm marking this one as solved now. The fix mentioned above is already in the