Pulp4 - Improve absolute and relative URL building

[bmbouter]

This is a discussion issue, not a RFE explicitly. What I've learned is that CONTENT_ORIGIN and the associated machinery to build absolute or relative URIs is in some ways re-solving what Django already solved.

As background, note that Pulp has two situations where code executes 1) in the request + response cycle of django 2) the request + response cycle of aiohttp.server and 3) in tasking. In Pulp3 we've tried to solve the building of absolute URLs for all cases in one go, with one setting, CONTENT_ORIGIN and some custom URL builder functions.

While we can't use Django machinery for aiohttp.server request+response, or in task processing, but consider this core django utility function: https://github.com/django/django/blob/8a6b4175d790424312965ec77e4e9b072fba188b/django/http/request.py#L148-L164 This seems well thought out that it:

• allows you to enable/disable HTTP_X_FORWARDED_HOST with a setting, e.g. USE_X_FORWARDED_HOST which is disabled by default
• attempts to use HOST as the next thing it tries
• attempts to use PEP 333 algorithm which uses SERVER_NAME and port

It would be good if Pulp worked this way for the django and aiohttp request + response handling, and in fact if we could just use the django build_url machinery (which all uses this underneath) we could get out of that business too. Figuring out how to get aiohttp.server to also do this will take some investigation, but at least it's a straightforward goal.

The only remaining issue then is what to do about places that aren't part of the request+response cycle, e.g. tasking, django-admin commands, etc. For those I think there needs to be either feature-by-feature defaults, environment variables, or maybe a site-wide default (like CONTENT_ORIGIN only used just for this subset of features). Anyways, producing URLs is tricky business so we need to think carefully about this aspect.

FYI @pulp/core

[mdellweg]

We need to communicate that removing this setting requires all installations to have the content app live behind the same fqdn. This is currently not a requirement, but we expect it to be satisfied by all installations anyway.