Guess the scheme if r.URL.Scheme is unset

[euank]

It's not expected that the request's URL is fully populated when used on
the server-side (it's more of a client-side field), so we shouldn't
expect it to be present.

In practice, it's only rarely set at all on the server, making mux's
Schemes matcher tricky to use as it is.

This commit adds a test which would have failed before demonstrating the
problem, as well as a fix which I think makes .Schemes match what
users expect.

This will technically break anyone who did the following:

router.Schemes("") // match http and https

[fharding1]

To back up it's only rarely set at all on the server:

https://golang.org/pkg/net/http/#Request

        // URL specifies either the URI being requested (for server
        // requests) or the URL to access (for client requests).
        //
        // For server requests, the URL is parsed from the URI
        // supplied on the Request-Line as stored in RequestURI.  For
        // most requests, fields other than Path and RawQuery will be
        // empty. (See RFC 7230, Section 5.3)
        //
        // For client requests, the URL's Host specifies the server to
        // connect to, while the Request's Host field optionally
        // specifies the Host header value to send in the HTTP
        // request.
        URL *url.URL

[fharding1]

This could benefit from some documentation on the Schemes methods of Router and Route

[euank]

I added some docs to Route.Schemes. Since Router just references the Route docs, it seems like that's the only place docs should be updated.

[euank]

I updated the test so it would have caught that typo and rebased it on master to pickup the CI config changes.

[elithrar]

@fharding1 - PTAL.

[fharding1]

I would say that the test case should be updated, but otherwise it looks good to me.

[fharding1]

Would it make sense for this test to have different responses for the different schemes so we can use that to differentiate? I believe this test would pass if the httpsServer subtest was matching on the http route.

[euank]

I think you're right. I made it so there's one router that has both matchers, and that each matcher has a different response. I think that should better test for what we care about.
Thanks for the review!

[elithrar]

Thanks for taking a look - agree that the test cases should be split out here.

…

On Sun, Oct 13, 2019 at 10:56 AM Franklin Harding ***@***.***> wrote: ***@***.**** requested changes on this pull request. I would say that the test case should be updated, but otherwise it looks good to me. ------------------------------ In mux_httpserver_test.go <#474 (comment)>: > @@ -0,0 +1,50 @@ +// +build go1.9 + +package mux + +import ( + "bytes" + "io/ioutil" + "net/http" + "net/http/httptest" + "testing" +) + +func TestSchemeMatchers(t *testing.T) { Would it make sense for this test to have different responses for the different schemes so we can use that to differentiate? I believe this test would pass if the httpsServer subtest was matching on the http route. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#474?email_source=notifications&email_token=AAAEQ4EK5NJT5U6Y5LUSQ4DQONOK7A5CNFSM4HNGM662YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCHY4UPA#pullrequestreview-301058620>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQ4HU6XK2B72RWSJK2NTQONOK7ANCNFSM4HNGM66Q> .

[fharding1]

@euank I'll take another look at this today

[fharding1]

This looks good to me

[elithrar]

Thanks both!