Skip to content

Proxito: pass unresolved domain in request #9982

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 20 commits into from
Feb 14, 2023
Merged

Proxito: pass unresolved domain in request #9982

merged 20 commits into from
Feb 14, 2023

Conversation

stsewd
Copy link
Member

@stsewd stsewd commented Feb 2, 2023

Make use of the unresolved domain from the request instead of each of the attributes we are setting in the request from the middleware, we aren't using any of those on .com, so we are safe removing them here.

This is on top of #9974.

@stsewd stsewd marked this pull request as ready for review February 6, 2023 23:07
@stsewd stsewd requested a review from a team as a code owner February 6, 2023 23:07
@stsewd stsewd requested a review from humitos February 6, 2023 23:07
Comment on lines 78 to 86
origin_to_description = {
OriginType.http_header: "rtdheader",
OriginType.custom_domain: "cname",
OriginType.public_domain: "subdomain",
OriginType.external_domain: "subdomain",
}
response["X-RTD-Project-Method"] = origin_to_description[
unresolved_domain.origin
]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we don't care about keeping the old names, we could also just use unresolved_domain.origin.name

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think nobody should be using this. We've used internally to know where we were getting this value from. I'm fine using new names here, but probably worth double checking with @ericholscher in case he has other concerns about this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, this is mostly just for debugging on our side. I don't think anything should be depending on it, but validatehttp would be the only place I'd think.

we set ``request.subdomain`` to `True`.
- If the project was extracted from a custom domain,
we set ``request.cname`` to `True`.
- Set ``request.unresolved_domain`` to the unresolved domain.
- If the domain needs to redirect, set the canonicalize attribute accordingly.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the canonicalize attributes are set here now, but I think we should be able to move these to the serve_docs view, since there is the only place we make use of them, maybe the http to https redirect could be done at the middleware level.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we have a bigger object? I'd like to inject one and only one object to the request with a known structure. As an example:

class DataRequest:
  unresolved_domain
  canonicalize
  # ... others we will add in the future

What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using these attributes in the docs view only, moving all the logic to the docs view serving should be easier

canonicalize_redirect_type = getattr(request, "canonicalize", None)
if canonicalize_redirect_type:
try:
# A canonical redirect can be cached, if we don't have information
# about the version, since the final URL will check for authz.
if not version and self._is_cache_enabled(final_project):
self.cache_request = True
return self.canonical_redirect(
request=request,
final_project=final_project,
version_slug=version_slug,
filename=filename,
redirect_type=canonicalize_redirect_type,
is_external_version=is_external,
)
except InfiniteRedirectException:
# Don't redirect in this case, since it would break things
pass

Once that is moved, not sure if there is anything else that we will need to inject in the request, but if we have the need, I'd be fine creating another object.

Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I left some suggestions to simplify it a little more.

Comment on lines 78 to 86
origin_to_description = {
OriginType.http_header: "rtdheader",
OriginType.custom_domain: "cname",
OriginType.public_domain: "subdomain",
OriginType.external_domain: "subdomain",
}
response["X-RTD-Project-Method"] = origin_to_description[
unresolved_domain.origin
]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think nobody should be using this. We've used internally to know where we were getting this value from. I'm fine using new names here, but probably worth double checking with @ericholscher in case he has other concerns about this.

we set ``request.subdomain`` to `True`.
- If the project was extracted from a custom domain,
we set ``request.cname`` to `True`.
- Set ``request.unresolved_domain`` to the unresolved domain.
- If the domain needs to redirect, set the canonicalize attribute accordingly.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we have a bigger object? I'd like to inject one and only one object to the request with a known structure. As an example:

class DataRequest:
  unresolved_domain
  canonicalize
  # ... others we will add in the future

What do you think?

Base automatically changed from refactor-proxito to main February 14, 2023 00:39
Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@stsewd stsewd merged commit 0622429 into main Feb 14, 2023
@stsewd stsewd deleted the refactor-proxito-x2 branch February 14, 2023 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants