Loving how awesome caddy is, and how easy it is to configure and use… on MacOS.
However, the primary goal is to get it working on a Windows platform. All good with setup and config, except that I can’t get Windows to recognize the Perl program I’m trying to back a websocket mapping. Here’s what that looks like in caddy.conf:
websocket /echo proxy.pl
proxy is just a Perl program that makes a local connection to a privileged port, and does simple IO. It works beautifully in MacOS, but on Windows, I get this in my error.log file:
“[ERROR 502 /echo] fork/exec proxy.pl: %1 is not a valid Win32 application.”
If I invoke proxy from a CMD shell, it does exactly what I want, but caddy seems unable to spawn the program itself.
I’ve added “.PL” to PATHEXT and done the “assoc” thingy, still no go.
Anyone have experience with this issue? I’d be incredibly grateful…
Is proxy.pl a Windows executable? (I’m guessing not.) You’ll probably have to invoke some perl interpreter that then runs that script instead…
Hi Matt - thanks for the response. No, it’s not a Windows exe, it’s a Perl file that should be interpreted by Perl.exe in the PATH. That’s how it works interactively, through CMD.
Does Caddy allow for a command+arguments syntax in the conf file, for websocket?
I believe it does, so
websocket /echo "C:\path\to\perl.exe proxy.pl" should be valid.
Thank you Matthew for that clarification!
I have tried many iterations of this sort of construct (all quoted, not quoted, forward slashes, back slashes, full path, relative path (let the PATH variable find the exe), with leading “C:”, without it, etc., but all attempts lead to this error from Caddy:
[ERROR 500 /echo] not supported by windows
I’ve even gone deep into the go programming for the Windows command parser, but this message does not appear there, so I assume it’s coming from the internals of Windows.
Could this be some kind of input/output constraint of Windows OS, or Administrative privilege constraint? Any way I can tease more diagnostic info out of the caddy installation?
Yeah, weird, I can’t find that exact error message anywhere either. It’s not in
os/exec as far as I can tell, and there are only two points you should get a Status 500 from the
websocket middleware that I can see…
I do note this in the package description for
Unlike the “system” library call from C and other languages, the os/exec package intentionally does not invoke the system shell and does not expand any glob patterns or handle other expansions, pipelines, or redirections typically done by shells.
Which probably explains why the
.pl file wasn’t being sent to
Also, glancing over
websocket's setup.go, it looked like they loaded in the entire next token and then split it up in order to get the cmd and args, so it had to be quoted if there were spaces (the token parser treats an opening quote to its closing quote as a single token). It’s always a good idea to quote file paths anyway, but Windows convention when launching a file with a program is always the full filepath starting with drive letter, with the file as the first argument, so that’s what I went with.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.