Resolved domain name is used as Host in Octoprint upload request breaking reverse proxies (Windows only probably)

[ro-kue]

Description of the bug

Background

I am 95% sure that this is a bug with PrusaSlicer and not a configuration problem on my end although I might be unaware of some Windows specific issues with DNS that cause this but I think this is unlikely too.

I have two printers both with their own OctoPrint instance that are running on the same machine (with Docker but that's irrelevant) in front of them is an Nginx server configured as a reverse proxy that is routing requests via *.lan domains. This is not really relevant to the bug but it explains why this is literally breaking reverse proxies.

Problem

I can add those instances without issues to a physical printer and PrusaSlicer will say that everything is fine. The API key works, all is good.

Once I slice something and try to upload it to OctoPrint, I just get an error that says "Error uploading to print host: HTTP 401: Unauthorized".

That is nonsense. I am authorized. I tried the global API key, I tried the user API key, I created an Application Key, the user has all permissions it could possibly have. There is no way in hell I am not authorized.

However, this does NOT happen on my work Mac which is why I'm so sure it's a PrusaSlicer issue. There everything works as expected.

Log files for OctoPrint are empty which threw me off for months because I was sure it's an OctoPrint issue. But this makes perfect sense once I explained it.

Explanation

Somewhere during the whole thing PrusaSlicer is trying to resolve the domain. It does that and sends the HTTP request for uploading the gcode. However, it is also setting the Host field in the HTTP header to the IP it resolved the domain to.

In my case, the Host header should be "drucki.lan" because that's where the instance is hosted and that's what the reverse proxy is looking for. This is also what a browser does and this is what PrusaSlicer does when it tries to verify the API key.

However, when uploading gcode, the Host header contains 192.168.0.3 which is the correct IP for my home server but doesn't hit octoprint because my reverse proxy doesn't really know what to do with this. I'm actually not sure where the error is actually coming from but that's an issue with my setup and not PrusaSlicer. It literally can't be OctoPrint though.

Screenshots

Here's the error that I'm getting.

Here's my physical printer config

Here's the Wireshark capture of the version check PrusaSlicer does that shows that the Host header is set to drucki.lan which is correct and how it should be.

Here's the Wireshark capture of the upload that clearly shows that the Host header is set to 192.168.0.3 which is the correct IP but should not be set in the Host header if I don't set it in my configs.

Here's the screenshot that shows that PrusaSlicer is pretty happy with the config in the config screen.

Here's a screenshot of a Wireshark capture on macOS showing that it's at least not happening on macOS (so probably a Windows problem). It's talking to the same OctoPrint instance. There is generally a lot more going on because the sliced model is larger.

Project file & How to reproduce

dns_resolve_bug.zip

As requested, project file is included.

1. Have OctoPrint installed somewhere where a domain or maybe also hostname MUST to be resolved. If it would work with the host IP only, it will probably just work.
2. Add the OctoPrint instance to a physical printer
3. (Optional) Start a wireshark capture with the following filter: "http and ip.addr == " where is the IP address of the host OctoPrint is running on (no <> or anything. Just the IP)
4. Click the test button in the physical printer config (should succeed)
5. Slice any model and upload to octoprint straight from PrusaSlicer (should fail)
6. Stop the capture. You should have 2 version checks (GET) with the hostname in the Host header and one POST request with the IP in the host header.

One way to maybe reproduce this locally (haven't tested it but might make it easier for you):

1. Get Octoprint running in Docker locally.. Call the service octoprint.
2. Put a nginx in the same docker compose file. Configure a very basic reverse proxy that is just routing everything with the server name "octoprint-test" to "octoprint:<1234>" where <1234> is the default port OctoPrint listens on in docker (no <> or anything). Expose any port to container port 80 (use 80:80 for least friction)
3. In your hosts file, map "octoprint-test" to 127.0.0.1
4. You should now be able to configure OctoPrint via your browser going to "octoprint-test".
5. Add octoprint-test to a physical printer

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.5.0+win64

Operating system

Windows 11 Home 22H2 Build 22621.1105 Installed on 2022-01-17 (so pretty fresh)

Printer model

Prusa Mini but happens with an Ender 5 too

[lukasmatena]

Thanks for the report. Could you please test it with 2.6.0-alpha3? There have been changes since 2.5.0 which may have solved it or changed the behavior.

[ro-kue]

Hi.

I tried uploading gcode with 2.6.0-alpha3 and the problem persists. Exact same capture in wireshark too.

And also the exact same behavior in PrusaSlicer (test works, upload doesn't).

[bubnikv]

Is your OctoPrint resolved using Bonjour (nodns) service?

The issue we are facing is that the zerodns resolve in Windows is not working reliably. I don't remember all the details, but I believe

1. It does not broadcast on all network interfaces, thus if you ran a virtual machine, you did not get a connection.
2. It does not work reliably if one opens / closes a connection and then opens a connection the second time. For some reason the 2nd resolve fails, maybe there is some timeout in Windows kernel that avoids too frequent broadcasts. We worked around this issue by copying the resolved IP address from the first session into the 2nd session, which seems to be the culprit of your connection issues.

We are looking for the options to solve your issues.

[ro-kue]

Nope. No Bonjour. Good old DNS. I run a DNS server on that machine that resolves *.lan domains to 192.168.0.3 where the reverse proxy is taking care of the rest.

The only issue I see with what you wrote is maybe the second option but only if you just treat every tld that is not official as being Bonjour. There's nothing on that server that uses Bonjour. If you actually check for Bonjour services, there is no way anything can resolve to the IP of that machine.

[kocikdav]

Hello, we have an idea what is causing the problem. Luckily there is an inner variable, that might help. Please follow these steps:

1. In PS use Help -> Show configuration folder. File explorer should popup.
2. Turn off PrusaSlicer.
3. Only after PS is off, return to file explorer and open PrusaSlicer.ini.
4. There should be line allow_ip_resolve = 1. Change it to allow_ip_resolve = 0.
5. Save PrusaSlicer.ini.
6. Try upload.

Please let us know if it helps as we still would have to find a way to fix this without the variable.

[ro-kue]

That actually worked! Thank you very much!

[kubispe1]

That actually worked! Thank you very much!
@ro-kue @kocikdav
I did not study the issue much, but could be closed?

[ro-kue]

Yeah the solution worked flawlessly.

Was I supposed to close this issue? I wasn't sure so I left this open.

[kubispe1]

@ro-kue Nice. Closing as solved. See you

[kocikdav]

@ro-kue We added changes that should help your issue. Would you try PrusaSlicer-2.6.0-beta3 without the allow_ip_resolve=0 option? The changes should be setting "Host" in HTTP headers to correct value.

[ro-kue]

Sorry for the delay (my son was born on the 19th of May, didn't get to do any 3D printing until now. And I also missed the GitHub email...).

It seems to work now with 2.6 just fine. However, some time in March I actually switched from having a DNS server in the basement with a not official tld to an actual domain and https. So my setup isn't the same anymore. I don't see how this would cause problems though.