Closed pimsierhuis closed 1 month ago
It can be fixed, is the application available so I can have something to test/verify with?
I didnt bother to put it on github yet. I can do that if its in a better state. I dont mind sending it to you, but think its not the easiest way to test. I think its easiest if I share a working and not working http request that you can paste in netcat or telnet? Im also of course more than happy to test myself (i can share the webbuilder config file)
Request that doesn't work (don't mind the gcode, it's still for smoothieware):
POST /sdfiles?t=1726906164255 HTTP/1.1
accept-language: en-US,en;q=0.9
accept-encoding: gzip, deflate, br, zstd
referer: http://localhost:4200/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
origin: http://localhost:4200
content-type: multipart/form-data; boundary=----WebKitFormBoundaryL3i4dTPiSwMHDFxQ
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
accept: application/json, text/plain, */*
sec-ch-ua: "Not)A;Brand";v="99", "Google Chrome";v="127", "Chromium";v="127"
content-length: 579
connection: close
host: localhost:4200
------WebKitFormBoundaryL3i4dTPiSwMHDFxQ
Content-Disposition: form-data; name="path"
/
------WebKitFormBoundaryL3i4dTPiSwMHDFxQ
Content-Disposition: form-data; name="visicut.gcodeS"
72
------WebKitFormBoundaryL3i4dTPiSwMHDFxQ
Content-Disposition: form-data; name="visicut.gcodeT"
2024-09-08T08:57:59
------WebKitFormBoundaryL3i4dTPiSwMHDFxQ
Content-Disposition: form-data; name="myfiles"; filename="visicut.gcode"
Content-Type: text/x.gcode
G0 X0 Y0 F30000
G4 P0.01
fire 100
G4 P0.04
fire off
M23 calibrate.gcode
------WebKitFormBoundaryL3i4dTPiSwMHDFxQ--
If you replace content-type with Content-Type and content-length with Content-Length, it works.
And here's my webbuilder config file:
Should be ok now - I'll leave it to you to test as I am not able to do comprehesive testing myself for now.
Tested and it works. Thanks again for the fast action Terje!
I try to upload files to grblhal via HTTP from an Angular application. This doesn't work, because the header-names Content-Type and Content-Length are sent in lower-case, but GrblHAL expects them in the mentioned case. As HTTP-header names should be case-insensitive (see https://datatracker.ietf.org/doc/html/rfc7230#section-3.2), this can be considered a problem of GrblHAL (and Angular will not fix it, see https://github.com/angular/angular/issues/16651)
Can this be fixed in grblhal? :)