title: In Go + FastCGI, does it make any sense to use multiple handlers?
body: <p>Gopher newbie here. Please be kind :-)</p>
  
  <p>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 <code>net/http</code>, but figuring out how to use it with <code>net/http/fcgi</code> seemed simple enough. Here is my minimal test application:</p>
  
  <pre><code>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)
      }
  }
  </code></pre>
  
  <p>Now this works beautifully and flawlessly: after compiling this to, say, <code>go-fcgi-test.fcgi</code> and placing it under the appropriate directory, the Go code is run from an URL like <code>http://my.shared.web.server/go-fcgi-test.fcgi</code>. 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.</p>
  
  <p>Let's try a slightly more complicated example:</p>
  
  <pre><code>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)
      }
  }
  </code></pre>
  
  <p>Now, in this scenario, I would expect <code>http://my.shared.web.server/go-fcgi-test.fcgi</code> to output <code>This comes from handler2</code>, and, indeed, that's exactly what happens.</p>
  
  <p>But why does <code>http://my.shared.web.server/go-fcgi-test.fcgi/first</code> actually invoke <code>handler2</code> as well, i.e. <code>handler1</code> is completely ignored? Note that <code>handler2</code> <em>does</em> get the <code>/first</code> bit of the URL — Apache is <em>not</em> stripping it out — because I can read <code>r.URL.Path[1:]</code> and confirm that this was the whole path sent to the Go application.</p>
  
  <p>All examples I've found on the Web using a similar skeleton for FastCGI show only <em>one</em> 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?</p>
  
  <p>(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 <em>several</em> handlers and not just one, etc. and so forth)</p>
  
  <p>My real world scenario is actually a small application that is supposed to run either as a stand-alone web server using <code>net/http</code> <em>or</em> 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 <code>fcgi.Serve()</code> as opposed to <code>http.ListenAndServe()</code>. But it would be nice to be able to use the routing ability of the <code>net/http</code> package with different handlers under FastCGI as well.</p>
  
  <p>Thanks in advance for any insight. And even if the answer is 'yes, that's <em>exactly</em> 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!)</p>