-
Notifications
You must be signed in to change notification settings - Fork 270
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
ngclient: consistent targets handled differently than legacy updater #1576
Comments
Could you file an issue against the specification?
Please let's fix that to do translation the same as legacy client.
What I think you're saying here is that https://example.com/foo is a valid URL and therefore seemingly a valid The specification has a lot of file-system assumptions baked in and we could be clearer here, all we specifically ask for in |
Yeah I think we talk about the same thing: If the base target URL is
In all of these cases the filename is I guess an empty string which we could of course still prefix with Alternatively we could also say that we expect the URLs to always contain a non-empty "filename": maybe not an unreasonable request but definitely something we should validate if we do expect it -- injecting and parsing the HASH from the middle of the URL is very tricky so unexpected data will break things. |
I'm not even 100% sure the file requirement makes sense in the context of target paths-- maybe it does does but we already know that many valid URLs don't cleanly map to local file paths so realistically a good client implementation needs to be prepared to handle almost any URL anyway, and that might not be any more difficult than handling "URLs that include a filename like part" |
Specification issue theupdateframework/specification#183 |
Actually I'm wrong about the last two, they are not valid target paths since its defined to be a path-relative-URL string so can contain only path segments. |
I am not sure why this example is considered a valid target path? |
"file" and "directory" are definitions that don't exist in URLs as far as I know so that definition is a bit suspect. Anyway, I'm not trying to argue about what is a valid target path (maybe we could start being more strict about it... in another issue), just pointing out some complications you might want to test for when doing the change at hand with the target path handling we have. EDIT: or in other words: the legacy updater will handle an "empty filename" just fine AFAICT so I think we should too. Then we can also discuss what are valid target paths |
The definition of consistent targets in the spec is quite bad (as we're working with a URL but the spec insists on talking about filenames) so I'm not really sure what it wants:
Spec on consistent targets in repository:
Spec on consistent targets when client builds the download URL:
Issue
a/b
will translate to a download url patha/{HASH}.b
a/b
to a download url path{HASH}.a/b
So there's a couple of hings here:
CC @MVrachev
The text was updated successfully, but these errors were encountered: