Need a method for relative URLs versus absolute URLs. (with possible solution)

[nickleman]

It would be nice if the url_for command allowed for generating relative URLs since that is the function available in other areas, like Jinja templates. It would be easy to do. The current url_for method is:

    def url_for(self, name: str, **path_params: typing.Any) -> str:
        router: Router = self.scope["router"]
        url_path = router.url_path_for(name, **path_params)
        return url_path.make_absolute_url(base_url=self.base_url)

But if modified to:

    def url_for(self, name: str, *, absolute_url:bool = True, **path_params: typing.Any) -> str:
        router: Router = self.scope["router"]
        url_path = router.url_path_for(name, **path_params)
        return url_path.make_absolute_url(base_url=self.base_url) if absolute_url else url_path

The default behavior wouldn't change and there would be a way to call it an get a relative "/home/" style url. This is handy when behind some proxies, load balancers, etc.

[alex-oleshkevich]

Maybe it makes sense to add build_url_for method that takes a configuration args and generates a final URL. Then url_for can stay as it is and for more complex use cases, users can call build_url_for method.

url = request.url_for('login') # https://example.com/login
url = request.build_url_for('login', scheme='http', hostname='anotherexample.com', port=8080, fragment='tab-2', query_params={"key": "value"}) # http://anotherexample.com:8080/login?key=value#tab-2

def build_url_for(path: str, path_params: dict, query_params:dict, scheme: str, port:int, fragment:str)

IMO, it is a simple change that adds a big value.

[nickleman]

I thought build_url_for requires the path, not the function name? So if you change the path mapping but not the function name, then you still have to update all your templates, versus url_for which takes the function name instead and returns the path for it. You are less likely to change the function name than you are to change a path (IMO). I'll take a look at the build_url_for function though to refresh my memory on that.

[tino]

I hope we can revise this.
@tomchristie quoting you from here: #538 (comment):

However it might be nice to not have to worry about this, and for us to just serve up relative urls by default, since there's less potential for misconfiguration that way.

I would really really like that! I've always been really annoyed by Wordpress by default having a schema and domain baked in everywhere, and I come from a mostly Django world where relative urls are the default, and for me seem to be so much simpler. The linked case of https vs http is one. Working locally with a port number in the URL that get's dropped is another.

If possible, I would like to be able to set a default on the App level for this, as a kwarg as proposed above still means that different locations can have different outcomes depending on how one implements it. Would that be a solution? I might be able to create a PR.

[tomchristie]

Would that be a solution? I might be able to create a PR.

I'm not sure. A good approach might be to suggest what the docs would be like and figure if you've got buy in from that perspective. Being explicit is also an option here... Eg.absolute_url_for and .relative_url_for(...). (?)