Proxito: canonical redirects don't need further inspection of the version/project/filename

[stsewd]

Currently, our canonical redirect logic expects to the current project/version/filename

readthedocs.org/readthedocs/proxito/views/serve.py

Lines 148 to 155 in c0c3f02

	return self.canonical_redirect(
	request=request,
	final_project=final_project,
	version_slug=version_slug,
	filename=filename,
	redirect_type=redirect_type,
	is_external_version=is_external,
	)

But in reality, we shouldn't need those, because:

• http to https redirects don't need any of that information, we just need to change the protocol!
• subproject redirects only need the project from the unresolved domain, and resolve that as main-project.rtd.io/projects/subproject/{path} (no need for version or filename!)
• canonical domain redirects don't need any of that information, we just need to change the domain! And for subprojects, we don't allow custom domains on subprojects, and they will be picked up in the previous redirect, so nothing to worry about.

Moving the execution of the http-https and to-canonical-domain redirects should be easy, moving the other one requires adding a new way of unresolving a project

readthedocs.org/readthedocs/core/resolver.py

Lines 173 to 176 in c0c3f02

	def resolve(
	self, project, require_https=False, filename='', query_params='',
	external=None, **kwargs
	):

this new way will just accept the project and return the root path of it, no versions, no translations, just the root (like it would be a single version), for example:

• project.rtd.io/
• docs.example.com/
• project.rtd.io/projects/subproject/
• docs.example.com/projects/subproject/

[ericholscher]

@stsewd I think the trade off here is that we end up with multiple requests, instead of a single request. I believe the original implementation was trying to get the user to the right place with 1 HTTP redirect. That said, if we can be smarter here with caching, it would be great, but multiple round trips to the server is also a huge source of slowness for users, and something to consider in design.

[humitos]

but multiple round trips to the server is also a huge source of slowness for users, and something to consider in design.

I think 1 HTTP redirect will be harder to implement correctly. Also, once implemented, I suppose the code will be harder to follow as well 😄

[ericholscher]

but multiple round trips to the server is also a huge source of slowness for users, and something to consider in design.

I think 1 HTTP redirect will be harder to implement correctly. Also, once implemented, I suppose the code will be harder to follow as well 😄

Yea... looking at the implementation, I really like the simplicity of it, so I think it's likely the correct approach. Just wanting to make sure we're considering the UX when we design it :)