File paths now respect tar spec + add n-quads #2459
Conversation
| ( | ||
| visitedPaths ++ reference.path, | ||
| duplicates ++ reference.path.filter(visitedPaths.contains), | ||
| invalids ++ reference.path.filterNot(validatePath), |
There was a problem hiding this comment.
Why do we differentiate between invalids and longIds? Aren't both invalid paths? I don't think we need this detail here.
A path is wrong if the filename is greater than 100 or if the whole path is greater than 255
There was a problem hiding this comment.
The long ids is only a concern if you don't provide a valid path.
The invalid paths are about the ones provided by the users that are rejected.
There was a problem hiding this comment.
In both cases the client would have to adapt the path, that's why I didn't see the need to treat that separately.
But if you think is clearer for the client with the custom rejections, that's fine too.
There was a problem hiding this comment.
The broken rule is not the same and the error message is not the same.
If you look at the rejection, the error message is generated according to the broken rules in order to try to be not too verbose.
|
the fact that we reject immediately is fine now, since we only offer tar. However, if we were to support zip for example, we wouldn't want to reject at this stage, but when fetching |
Fixes #2412
Fixes #2363
Also: