Trying to download GCode from the http web interface on a port other than 80
For the gcode file to download.
404 - File Not Found (because the link contains no port information)
Yes
OctoPrint 1.3.5 (master branch)
OctoPi 0.14
Creality CR-10 Stock
Edge, Windows 10
Chrome, Windows 10
Firefox, CentOS 7
Internet Explorer, Windows 7
Not applicable
Not applicable
Screenshot attached
I have read the FAQ.
Hi @BinoX,
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read 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 but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.
Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.
Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.
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 2017-11-27 13:20 UTC) 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!
Best regards,
~ Your friendly GitIssueBot
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.
Hmm... I'm not able to replicate this behavior. How is the proxy configured?
I'll post up my config in about a hour. It's an NGINX reverse proxy set up, which I use quite a lot for this kind of task...
I've also noticed that it happens for downloading log files as well, but downloading timelapses is fine
That sure is one long hour ;)
Any updates on the config?
Whoops! Terribly sorry, I completely forgot I posted this... Remembered when I tried to use it again earlier.
I use a similar config for other sites and services and they all work fine... Maybe Octoprint requires some extra settings...
Anyway here is my nginx config:
server {
listen 8000;
server_name _;
location / {
proxy_pass http://192.168.0.34:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Change proxy_set_header Host $host; to proxy_set_header Host $http_host;
OctoPrint needs to know what port a request is coming in on or it will assume the default port for the URL scheme. For that it will evaluate - in that order - the X-Forwarded-Hostheader, the Host header and the X-Forwarded-Server and X-Forwarded-Port headers.
Nginx' $host variable does never contain the port number (see also here). So if you do something like proxy_set_header Host $host;, if you connect then via http://example.com:8080 your nginx will only forward Host: example.com and quietly throw away the port number. So for lack of alternative information OctoPrint will default to the scheme default port 80 in such a case.
$http_host on the other hand is the actual Host header sent with the request, including the port number (so example.com:8080) - so use that and all will work just fine. Alternatively you can also use $host:$server_port - see the examples.
OctoPrint does generate some absolute URLs server side based on the incoming request on API responses that are used for downloads and such in the frontend - that's why it also needs the full port information. Other services might only generate relative URLs which then magically work even though the server only gets half of the facts.
Whoops, feeling a little embarrassed now. I've been administering Nginx (and various other systems) servers for years and I totally didn't see that I had only put $host instead of $http_host
I should know better than that! Fallen into the "blame everyone except myself" trap. I think I must have used one of my "trick" configs as a template (I have a few services that do not like anything other than the standard port being used... I did not write them!!!!)
Anyway,
Many thanks for showing me my mistake. Donation en route
Most helpful comment
Whoops, feeling a little embarrassed now. I've been administering Nginx (and various other systems) servers for years and I totally didn't see that I had only put $host instead of $http_host
I should know better than that! Fallen into the "blame everyone except myself" trap. I think I must have used one of my "trick" configs as a template (I have a few services that do not like anything other than the standard port being used... I did not write them!!!!)
Anyway,
Many thanks for showing me my mistake. Donation en route