-
Notifications
You must be signed in to change notification settings - Fork 849
cachekey: added --key-type to allow parent selection URL to be modified #5872
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
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will return an error if the key is not a url. It's rather significantly less picky than it probably ought to be about what constitutes a URL, but if the separator is set to zero and no prefix is used, user input can cause this to fail. Consider these parameters:
With this request:
http://localhost/://-@@That creates a URL that doesn't parse. Likewise, using an invalid URL char in the separator will create URLs that don't parse.
If this cache key genuinely needs to be a valid URL, we should document that and think carefully about what sorts of request URLs could violate that. It might even be worth encoding the components in something like base64 to prevent user input from affecting the parent selection algorithm here.
If it doesn't need to be a valid URL (and I'm not entirely certain why it would need to be a URL, if you're just hashing it later), then we should avoid parsing it as one.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alficles Currently proxy/ParentConsistentHash expects that, cache_info_parent_selection_url, is a URL. The function ParentConsistentHash::getPathHash() uses the path in the url to create a hash. So in this case If it fails to parse the key, an error is logged and the parent selection url is not set and the original request url would be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What then, should the strategy be around ensuring that a given key will form a URL? The example provided in the docs produces lines that look like:
And that's definitely not a URL, although the exceptionally generous parser ATS uses will happily take it. How does a user know that that's a valid URL and what portion of it will be used for parent selection?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alficles The override to the parents selection url needs to be type URL. parent selection then makes a call to
ps_url->string_get_ref(&len);which returns a normalized path string with escape sequences which is used to create the PS hash. See ParentConsistentHash::getPathHash(). So it looks like cachekey creates a URL with a path string/hostname/port/path/to/content/querystringwhich is then normalized with escape sequences as necessary before creating a hashUh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alficles hopefully the following plugin design info brings some clarification.
The
cachekeyplugin is designed to provide an easy and somewhat structured way to set cache key (and now parent selection URL) by performing the following.It is a simple and generic design which would allow to keep enhancing with:
remappedandpristinerequest URI)The plugin does not get into the validation business which makes it generic and powerful.
The syntax validation is left to the lower level using the core API call. If the call fails it means that the transformation result is invalid, so the target should be (ideally) unchanged and an error message should be issued to the log. Pre-validation would be inefficient, error prone and would require unnecessary maintenance (keeping the two validations in-sync).
The semantic validation is left to the traffic server operator who ultimately knows the final goal (i.e. how the content should be cached or how the multi-tier caching should work).
It is true that one can easily shoot oneself in the foot but it is not feasible and also very limiting to code all use-cases into the plugin and even then we would still need to make sure it works in production.
HTH
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. It feels like a bit of a footgun if you're not careful, but it's definitely useful. (And indeed I envision using it in the not-to-distant future.) Thanks!