Windows: factcgi /php php Bad Gateway 502 about caddy HOT 36 CLOSED

@alber70g
According to your Caddyfile.

navigating to /md will be handled by markdown
navigating to /php will be handled by fastcgi with php.

On which path are you getting 502 ?

from caddy.

@abiosoft I'm getting the error on /php.

from caddy.

@alber70g What port is fastcgi running on ? You need to have php-cgi.exe running.
Then modify your Caddyfile to include the fastcgi server.

localhost:2020
markdown /md
fastcgi /php 127.0.0.1:9000 php 
log access.log
errors error.log

from caddy.

@abiosoft Thank you! I've got it running now. I din't have a port specified when starting php-cgi: php-cgi -b 127.0.0.1:9000.

from caddy.

Glad its working now.

from caddy.

Pro tip: Adding

startup "php-cgi -b 127.0.0.1:9000"

to your Caddyfile will launch php-cgi when Caddy starts. You can also turn it off in a similar way with the shutdown directive.

from caddy.

@mholt Yes, thats what I thought aswell, but that isn't working. It totally doesn't do what it should. It seems like it stops sending requests anywhere, or it stops starting.

Current config:

127.0.0.1:2020
startup "php-cgi.exe -b 127.0.0.1:9000"
fastcgi / 127.0.0.1:9000 php {
    ext .php
    index index.example.php
}
markdown /md
log access.log
errors error.log

I can see that php-cgi starts (is visible in the task manager: php-cgi -b 127.0.0.1:9000

So php-cgi starts seemingly correct. But after that nothing works. I get ERR_CONNECTION_REFUSED in Chrome on both localhost:2020 and localhost:2020/md/test.md.

Is there some sort of verbose mode to see what is going on?

from caddy.

What does your error log say? Also, are you running Caddy as downloaded from the website or from source?

(Also, you don't need ext .php in the fastcgi block - that's already set when you specified the php preset)

from caddy.

The error log is empty. And I've downloaded it from the website.

from caddy.

Okay. Are you loading "localhost:2020" or "127.0.0.1:2020" in the browser? Try both and let me know.

from caddy.

I'm trying both. They don't show anything and give no errors in the error log

from caddy.

Phooey. Can you strip everything out of your Caddyfile (except the first line) and try it? Then add in one line at a time, retrying each time. And report back which line causes it to stop working? This will help us track down where I need to add some trace statements for a verbose/debug mode.

from caddy.

Only

127.0.0.1:2020

Gives: No such host at 127.0.0.1:2020

startup "php-cgi -b 127.0.0.1:9000"
127.0.0.1:2020

Gives: ERR_CONNECTION_REFUSED.

I'd say this should be enough. Everything I add after will result in ERR_CONNECTION_REFUSED.

When I start it separately it runs. Maybe because the startup is blocking, it just stops after running that command. Is there a way to start php-cgi silently/non-blocking?

from caddy.

I was thinking that would be the problem. So I found a small tool to start php-cgi non-blocking. http://wiki.nginx.org/PHPFastCGIOnWindows here is a tool mentioned called RunHiddenConsole.exe which can be used. Config looks like this now

localhost:2020, 127.0.0.1:2020
#startup "runhiddenconsole php-cgi -b 127.0.0.1:9000"
fastcgi / 127.0.0.1:9000 php {
    index index.example.php
}
markdown /md
log access.log
errors error.log

Of course i put RunHiddenConsole.exe in my path

from caddy.

That would do it, indeed. There isn't currently a way to run a command in the background, but there needs to be. I'm working on that right now, so you don't have to use an external tool.

When this is done today, you can suffix the command with & (like in Linux) to run it in the background, for example:

startup php-cgi -b 127.0.0.1:9000 &

(I'm also eliminating the need for the quotes)

from caddy.

Ah that would be awesome indeed. If you want I can do further testing when it's finished 👍

from caddy.

Excellent. Would you like me to send you an updated binary or do you have Go installed?

Thanks for your help, by the way.

from caddy.

I can install Go and create my own binary for Windows. It shouldn't be too much hassle. If you can easily provide a birnary that is also nice.

from caddy.

I've just pushed the fix. Here's a modified binary for you (I will delete it after today): https://drive.google.com/file/d/0B-OxZ0LoeTvGR2NpWDNNVk1pN0U/view?usp=sharing

from caddy.

localhost:2020, 127.0.0.1:2020
startup php-cgi -b 127.0.0.1:9000 &
fastcgi / 127.0.0.1:9000 php {
    index index.example.php
}
markdown /md
log access.log
errors error.log

2015/05/05 19:15:04 GetFileInformationByHandle /dev/stdin: The handle is invalid.

from caddy.

Okay, I've added stdin: https://drive.google.com/file/d/0B-OxZ0LoeTvGUndfTTNfNG93ckE/view?usp=sharing

from caddy.

I'm getting the same error now.

from caddy.

I got it running from source now so you can just push changes. I assume I need to do go get github.com/mholt/caddy to get the latest version? Is that correct?

And then go install and run the caddy.exe.

[edit]
I see I can just do a git pull. Then go install and run caddy.exe.
[/edit]

from caddy.

Yep. And go get -u github.com/mholt/caddy will update the project if you already have it on your computer.

Well, this has me stumped for now. I'll keep working on it... really appreciate your patience and feedback. If you'd like, feel free to take a look yourself. The error comes from here. It's low-level stuff but I'm probably just missing something obvious up in the startupshutdown.go file. The thing is, it works on Unix systems.

from caddy.

@alber70g Can you replace this line with:

cmd.Stdin = strings.NewReader("")

Then you can just do go run main.go from the project directory to build and run it right away. Does that fix it?

from caddy.

Nope, doesn't fix it. Get the same error.

from caddy.

Geez. What if you put a string in there like "Hello world" or something? I'm trying to determine why Windows thinks it's being given an invalid Stdin...

from caddy.

Could it have to be something like this (it's Python but has to do Windows handles Stdin: https://bugs.python.org/issue3905)

I'll try the "Hello world"

from caddy.

String in there doesn't gives an error. If you ment to do just cmd.Stdin = "sdf":

config\setup\startupshutdown.go:43: cannot use "sdf" (type string) as type io.Reader in assignment:
        string does not implement io.Reader (missing Read method)

Seems like the implementation of os.Stdin isn't right?

from caddy.

Sorry, I meant inside strings.NewReader("")

Like this: strings.NewReader("Hello world") - and that works, you say?

from caddy.

In the strings.NewReader("Hello world") gives the same The handle is invalid.

Maybe this will give some sort of a solution: http://stackoverflow.com/questions/23166468/how-can-i-get-stdin-to-exec-cmd-in-golang

from caddy.

Okay, so the bug is not coming from the startup directive. I was able to reproduce this with help from a friend who has Windows and even without a Caddyfile, the same error was printed at startup. The error is actually coming from here in main.go.

On Windows, when there is no data piped to Caddy, it brings up that error. When data is piped to Caddy, the error goes away, but then the application hangs on the ioutil.ReadAll call a few lines below, presumably because no EOF is reached. (That was tested by doing echo "localhost:1234" | caddy on Windows - I imagine echo is appending a line break?)

I need to do more research about how to tame stdin on Windows.

from caddy.

Nice that you found that out. I'll just wait until you have a new version ;). I'm not good enough in Go to try things out myself. I really appreciate that you are so fast responding. Thanks a lot.

from caddy.

@alber70g No problem - I got a Windows VM running and was able to, I think, find a cross-platform solution to the problem. Would you please pull the latest (go get -u github.com/mholt/caddy should do it) and see if it works?

If not, ensure that lines 106-108 of main.go look exactly like this:

// stdin
fi, err := os.Stdin.Stat()
if err == nil && fi.Mode()&os.ModeCharDevice == 0 {

from caddy.

Awesome! It's working fluently now :) Thanks a lot. I really appreciate your fast response!! Awesome!

from caddy.

Cool - thank you so much for your help and patience!

from caddy.