Invalid request.url when full URI is used as SERVER_NAME

[PromyLOPh]

Describe the bug
When using a full URL as config.SERVER_NAME the request’s URL (request.url) is invalid, as it contains two colons. The code does not properly split the SERVER_NAME, keeping the colon. Splitting on "://" instead works for me, but the code remains very fragile.

Code snippet

from sanic import Sanic
from sanic.response import text

app = Sanic("MyHelloWorldApp")
app.config.SERVER_NAME = 'https://www.example.com/api'

@app.get("/foo")
async def foo_handler(request):
        return text(f'{request.url}')

$ curl localhost:8001/foo
https:://www.example.com/foo

Expected behavior
The URL should be valid.

$ curl localhost:8001/foo
https://www.example.com/foo

Environment (please complete the following information):

• OS: Linux-5.4.0-110-generic-x86_64-with-glibc2.33
• Version Sanic v21.12.1

[sjsadowski]

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.

[Tronic]

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.

[sjsadowski]

@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

[PromyLOPh]

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.

[ahopkins]

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.

sanic/sanic/request.py

Line 715 in 5d683c6

return self.app.config.SERVER_NAME.split("//")[0]

[PromyLOPh]

Sure, I can prepare a PR.