Decouple CORS from TrieServeMux

[rcrowley]

@mihasya

I'm not sure how plausible this is but it would be nice for CORS to work without assuming a TrieServeMux. From IRC:

[11:41:46] <submersive>  rcrowley: looking at tigertonic cors stuff, confused as to how this works with options well?
[11:43:36] <submersive>  it doesn't look like it knows the allowed methods or accepts/provides content types?
[11:43:43] <rcrowley>    submersive: mihasya actually wrote the CORS support so hopefully he's around.  As far as I remember, OPTIONS is handled correctly by tigertonic.TrieServeMux with some added headers for CORS.
[11:44:00] <submersive>  ah with Trie Mux
[11:44:22] <submersive>  been using gorilla mux since we match on uuid's
[11:44:35] <submersive>  I'll take a closer look, thanks
[11:45:00] <rcrowley>    Ah, that explains it.
[11:45:33] <rcrowley>    submersive: I'd like to decouple those components; they really don't have anything to do with each other except for the collision on header names.
[11:46:21] <submersive>  rcrowley: yeah, really need something to build out that metadata somehow
[11:46:42] <submersive>  like I guess java has that jax-rs, erlang has the webmachine/cowboy_rest thing
[11:47:27] <submersive>  nothing really like that for go except I guess go-restful, but its all tied in with go-restful so harder to mix'n'match like with tigertonic and gorilla (I like tigertonic and gorilla)
[11:48:33] <submersive>  I guess a fancier mux could do that
[11:51:59] <rcrowley>    submersive: the key's really http.ResponseWriter.Header() and some agreement about how to cooperatively add/modify headers.  I think for CORS it's solvable.  I'll ping mihasya, who doesn't appear to be online right now.

[mihasya]

WELL, what I think you would need for this is some notion of conditional handling based on what the http method is, similar to Django's class based views. The way this MIGHT work in the go/tigertonic world is by having an additional interface for different methods that a handler might implement. SUCH AS:

type OptionsHandler interface {
    HandleOptions(ResponseWriter, *Request)
}

You would then want your framework (tigertonic or otherwise) to somehow wrap whatever handlers you have in something that can do a type switch on the actual handler to see if it also is an OptionsHandler and invoke HandleOptions. The thing is though, I think it would still have to do the sort of magic that trie_serve_mux.go does now because that's really the only way to know which methods have been registered with the mux, UNLESS you go full bore and just register an opaque handler object at a path, and then rely on the interfaces it implements (PostHandler, GetHandler, etc) to do OPTIONS and route the request to the appropriate method or a 405.