Gopher newbie here. Please be kind :-)
I have a setup where I do have an account on a shared server which runs Apache + FastCGI over which I have no control. It smoothly interfaces with Go, though. I'm more used to using Go with net/http, but figuring out how to use it with net/http/fcgi seemed simple enough. Here is my minimal test application:
package main
import (
"fmt"
"net/http"
"net/http/fcgi"
)
func handler(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Header().Set("Content-type", "text/plain; charset=utf-8")
fmt.Fprintln(w, "This was generated by Go running as a FastCGI app")
}
func main() {
/*
*
* Everything that is done here should be setup code etc. which is retained between calls
*
*/
http.HandleFunc("/", handler)
// This is what actually concurrently handles requests
if err := fcgi.Serve(nil, nil); err != nil {
panic(err)
}
}
Now this works beautifully and flawlessly: after compiling this to, say, go-fcgi-test.fcgi and placing it under the appropriate directory, the Go code is run from an URL like http://my.shared.web.server/go-fcgi-test.fcgi. For the sake of simplicity, I've left most of the actual processing out — but this works perfectly with extracting form parameters, ENV variables (under Go 1.9!) and so forth, so I know that the basic setup must be ok.
Let's try a slightly more complicated example:
package main
import (
"fmt"
"net/http"
"net/http/fcgi"
)
func handler1(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Header().Set("Content-type", "text/plain; charset=utf-8")
fmt.Fprintln(w, "This comes from handler1")
}
func handler2(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Header().Set("Content-type", "text/plain; charset=utf-8")
fmt.Fprintln(w, "This comes from handler2")
}
func main() {
http.HandleFunc("/first", handler1)
http.HandleFunc("/", handler2)
if err := fcgi.Serve(nil, nil); err != nil {
panic(err)
}
}
Now, in this scenario, I would expect http://my.shared.web.server/go-fcgi-test.fcgi to output This comes from handler2, and, indeed, that's exactly what happens.
But why does http://my.shared.web.server/go-fcgi-test.fcgi/first actually invoke handler2 as well, i.e. handler1 is completely ignored? Note that handler2 does get the /first bit of the URL — Apache is not stripping it out — because I can read r.URL.Path[1:] and confirm that this was the whole path sent to the Go application.
All examples I've found on the Web using a similar skeleton for FastCGI show only one handler. Is this a limitation of the FastCGI package itself? A limitation of the FastCGI protocol (but then why is the whole path correctly sent?)? Something done at the Apache configuration which imposes this limitation (remember, I cannot touch the Apache configuration)? Or am I doing something terribly wrong?
(For the sake of completeness, I should add that yes, I have tried out several variations of the above, renaming the Go app, using subfolders, using several handlers and not just one, etc. and so forth)
My real world scenario is actually a small application that is supposed to run either as a stand-alone web server using net/http or as a FastCGI application in the case that the stand-alone model is either not supported or even forbidden (which is the case of some providers of shared environments). Since the actual handling is exactly the same for either case, the only difference is calling fcgi.Serve() as opposed to http.ListenAndServe(). But it would be nice to be able to use the routing ability of the net/http package with different handlers under FastCGI as well.
Thanks in advance for any insight. And even if the answer is 'yes, that's exactly how the FastCGI implementation works under Go — one handler only!' that would still be useful — meaning that I just need to work around my own code and do things differently (basically, creating my own router/dispatcher based on parameters passed through the Form interface — no big deal, it's doable!)
