-
Notifications
You must be signed in to change notification settings - Fork 56
Description
When the specification talks about consistent targets, it always refers to filenames. Here is 6.2.1. Writing consistent snapshots:
consistent target files should be written to non-volatile storage as digest.filename.ext
Here is 5.7.3 talking about building the download URL in client:
the filename is of the form HASH.FILENAME.EXT
The issue is that in both cases what we are really interested in is the target path (which is really part of a target URL) and how the hash is used produce the target URL (on client) or how it is parsed from a target URL (on repository). The spec should define how to do URL construction instead of defining filename construction.
https://theupdateframework.github.io/specification/latest/#targetpath does limit target path to just URL path segments (so according to that query and fragment parts would not be allowed in target path).
So:
- Injecting hash into and parsing the hash from target URL should be defined instead of talking about filenames
- if the valid target paths are restricted by spec, those restrictions should be stated (e.g. must a filename part be non-empty?)
- Preferably examples should be given
Some potential target path examples:
a
a/b
a%2Fb
a\b
a/
?a=b # query, so not allowed according to strictest targetpath definition
#a # fragment, so not allowed according to strictest targetpath definition
In all of these cases we can figure out a "filename like component" (in last 3 the filename is an empty string) and we can of course prefix that with {HASH}.
. Alternatively the spec could require the target path to contain a non-empty filename element ("filename" is not a thing that really exists in URLs but I assume we could).