Crash after sending print to Creality K1 Max via LAN (HTTP 405 from upload endpoint) #723

New Issue

MrUnknownDE · 2026-04-05T16:27:25+02:00

MrUnknownDE commented

2026-04-05 16:27:25 +02:00

Originally created by @scarter4work on 2/16/2026

Description

OrcaSlicer crashes immediately after successfully sending a print job to a Creality K1 Max over LAN. The print job is received and starts on the printer, but OrcaSlicer itself crashes during/after the upload process.

Steps to Reproduce

Slice a model for Creality K1 Max
Send the print job to the printer over LAN (printer running Klipper/Moonraker on port 4408)
The gcode uploads and the print starts on the printer
OrcaSlicer crashes

Error Log

From ~/.config/OrcaSlicer/log/:

[error] Creality Print: Error uploading file to http://<printer-ip>:4408/upload/<filename>.gcode: , HTTP 405, body: `<html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.17.7</center>
</body>
</html>
`

The printer has been flashed from stock Creality Print firmware to Klipper. It appears OrcaSlicer successfully sends the print via Moonraker's API, but then also attempts a Creality Print-specific upload to the /upload/ endpoint which no longer exists under Klipper. The HTTP 405 response from this secondary request crashes the application instead of being handled gracefully.

Environment

OrcaSlicer version: v2.3.2-beta2 (build 7e63fce7)
OS: Nobara Linux 43 (Fedora-based), KDE Plasma, Wayland
Printer: Creality K1 Max — flashed to Klipper (Moonraker/nginx 1.17.7 on port 4408)
Installation: AppImage (Ubuntu 24.04 build)

Expected Behavior

OrcaSlicer should handle the HTTP 405 response gracefully (log the error, possibly show a non-fatal warning) rather than crashing. The print job itself is delivered successfully via Moonraker, so the crash is unnecessary. Ideally, OrcaSlicer should not attempt the Creality Print upload path when communicating with a Klipper-based printer.

Additional Context

The log also shows some non-critical errors related to bed model/texture paths referencing Windows paths (D:\Backup\OS\...) from a previous config migration, but these are unrelated to the crash.

*Originally created by @scarter4work on 2/16/2026* ## Description OrcaSlicer crashes immediately after successfully sending a print job to a Creality K1 Max over LAN. The print job is received and starts on the printer, but OrcaSlicer itself crashes during/after the upload process. ## Steps to Reproduce 1. Slice a model for Creality K1 Max 2. Send the print job to the printer over LAN (printer running Klipper/Moonraker on port 4408) 3. The gcode uploads and the print starts on the printer 4. OrcaSlicer crashes ## Error Log From `~/.config/OrcaSlicer/log/`: ``` [error] Creality Print: Error uploading file to http://<printer-ip>:4408/upload/<filename>.gcode: , HTTP 405, body: `<html> <head><title>405 Not Allowed</title></head> <body> <center><h1>405 Not Allowed</h1></center> <hr><center>nginx/1.17.7</center> </body> </html> ` ``` The printer has been flashed from stock Creality Print firmware to **Klipper**. It appears OrcaSlicer successfully sends the print via Moonraker's API, but then also attempts a Creality Print-specific upload to the `/upload/` endpoint which no longer exists under Klipper. The HTTP 405 response from this secondary request crashes the application instead of being handled gracefully. ## Environment - **OrcaSlicer version**: v2.3.2-beta2 (build 7e63fce7) - **OS**: Nobara Linux 43 (Fedora-based), KDE Plasma, Wayland - **Printer**: Creality K1 Max — **flashed to Klipper** (Moonraker/nginx 1.17.7 on port 4408) - **Installation**: AppImage (Ubuntu 24.04 build) ## Expected Behavior OrcaSlicer should handle the HTTP 405 response gracefully (log the error, possibly show a non-fatal warning) rather than crashing. The print job itself is delivered successfully via Moonraker, so the crash is unnecessary. Ideally, OrcaSlicer should not attempt the Creality Print upload path when communicating with a Klipper-based printer. ## Additional Context The log also shows some non-critical errors related to bed model/texture paths referencing Windows paths (`D:\Backup\OS\...`) from a previous config migration, but these are unrelated to the crash.

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#723