In Go + FastCGI, does it make any sense to use multiple handlers?

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!)

I realize this is an old post, but I'm just starting to play with Go and fcgi myself and came across this same issue.

The short answer is yes, it does make make sense to use multiple handlers. The flaw in your example is that you aren't accounting for the go-fcgi-test.fcgi being part of your URL.

When Go's ServeMux processes the URL, it is using the full URL of the request, not just the part being handled by your fcgi process. In the case of http://my.shared.web.server/go-fcgi-test.fcgi/first, the program is looking for the closest match to /go-fcgi-test.fcgi/first, which is /.

Update 2023-02-24: I was completely wrong in the assumptions below. @Kodiak was right, I just didn't quite get it. A few years later, and, thanks to @Hudon who commented below (and perhaps a bit more experience...), I'm rejecting this old answer of mine, and accepting @Kodiak's as the correct one (which it is).

I'm just letting the following remain for historical purposes. It's not 'completely wrong', mind you; but it is based on my ignorance of what the actual URL was being passed to ServeMux. Now I know

<strike>After reading the answer provided by @Kodiak, I re-read the documentation for ServeMux and came across this paragraph:

> Note that since a pattern ending in a slash names a rooted subtree, the pattern "/" matches all paths not matched by other registered patterns, not just the URL with Path == "/".
>
> If a subtree has been registered and a request is received naming the subtree root without its trailing slash, ServeMux redirects that request to the subtree root (adding the trailing slash). This behavior can be overridden with a separate registration for the path without the trailing slash. For example, registering "/images/" causes ServeMux to redirect a request for "/images" to "/images/", unless "/images" has been registered separately.

(italics mine)

My assumption was that ServeMux pretty much behaved as the rule-based pattern matching features of nginx and/or Apache's rewrite module, i. e. rules are processed according to the order they're registered, and therefore I was expecting that /first would be matched first (pun intended), and only if no match was found, / would be matched next.

But this is not what the documentation says. Instead, the order of registration makes no real difference; ServeMux, in my given scenario, because I forgot adding a trailing slash, will always 'fall back' to the handler for "/", not because of some bug or perversion of the matching algorithm, but because that is the intended behaviour as coded by the Go developers! In other words, if you have a handler for "/", it acts as a catch-all for every non-slash-terminated subtree.

I just failed to read the documentation properly! (or maybe back in 2017 that paragraph wasn't clear enough)</strike>