https://www.example.com/api is not a valid server name, it is a complete URI. With that being said, '/' is an invalid character for a hostname, and this should be throwing an error. It should also be documented that SERVER_NAME should be RFC1123 compliant when used.

We will look at including an appropriate fix that errors out when using invalid characters and document this appropriately.

Was something changed? I recall myself implementing support for full URL SERVER_NAME a few years back, although IIRC it wouldn't (yet) support path but at least you could say https to provide correct scheme on external URLs instead of http as used when running behind Nginx.

@Tronic It hasn't changed, but the internal documentation refers to it being used when host_name isn't present, which in itself is probably wrong. In reality there probably needs to be an "external_url" config item that passes a full path when needed.

In reality, it's not well documented, and since everyone can interpret server_name differently, it probably should be documented specifically.

It's also concerning because the colon issue may be problematic if using an IPv6 address which probably needs investigation as well.

ref: https://sanic.readthedocs.io/en/stable/sanic/api/app.html -> url_for section

As a bit of background: I am trying to host a sanic application behind a nginx reverse proxy mounted on a non-root path. Unfortunately the documentation provides no information on how to do this and standard ASGI with a root_path does not work. Instead #1731 suggest to use SERVER_NAME with a path, which works for url_for, but then I run into the issue reported here. I’m using request.url and the Origin header to prevent XSRF.

This is indeed a bug.

app = Sanic(__name__)
app.config.SERVER_NAME = "http://www.myserver.com/nested"


@app.get("/handler")
async def handler(request: Request):
    return json(
        {
            "url": request.url,
            "scheme": request.scheme,
            "host": request.host,
            "path": request.path,
        }
    )

{
  "url": "http:://www.myserver.com/handler",
  "scheme": "http:",
  "host": "www.myserver.com",
  "path": "/handler"
}

@PromyLOPh would you be willing to submit a PR for us? Should be a small fix to parsing of the scheme. It is just a matter of adding .strip(":") to the end of this line and hopefully adding a test or two.

Sure, I can prepare a PR.