fix: discard dot segments from subpath #176
Conversation
dwalluck
force-pushed
the
fix-parse-path
branch
3 times, most recently
from
6cb7290 to
8a03dd6
Compare
| if (".".equals(segment) || "..".equals(segment)) { | ||
| if (!isSubpath) { | ||
| throw new MalformedPackageURLException("Segments in the namespace must not be a period ('.') or repeated period ('..'): '" + segment + "'"); | ||
| } |
There was a problem hiding this comment.
I can't actually find any mention of namespace not containing dots, but I left the code as it was.
There was a problem hiding this comment.
Isn't the condition inverted? Segments in the subpath can not be neither . nor .., but no such condition exists for namespace.
There was a problem hiding this comment.
I agree that it looks inverted compared to the original code, but I think it is the behavior intended by the test cases:
- If
!subpath, i.e.,namespace, then if.or..appears it's an error. - If
subpath, then discard it without error and don't add it to the results.
There was a problem hiding this comment.
I think it's confusing because there are two methods, parsePath and validatePath, and they don't share the same code.
One is pre-decoding and silently filters paths there, and one is post-decoding. Probably, there is some way to refactor it to make this clearer, but I haven't figured it out yet.
There was a problem hiding this comment.
I added a test case. Does it make sense?
dwalluck
force-pushed
the
fix-parse-path
branch
4 times, most recently
from
6fc05ab to
db191ad
Compare
dwalluck
changed the title
dwalluck
force-pushed
the
fix-parse-path
branch
3 times, most recently
from
2fa4d68 to
c4171ea
Compare
| if (".".equals(segment) || "..".equals(segment)) { | ||
| if (!isSubpath) { | ||
| throw new MalformedPackageURLException("Segments in the namespace must not be a period ('.') or repeated period ('..'): '" + segment + "'"); | ||
| } |
There was a problem hiding this comment.
Isn't the condition inverted? Segments in the subpath can not be neither . nor .., but no such condition exists for namespace.
| assertEquals(subpath, purl.getSubpath()); | ||
| //assertEquals(subpath, purl.getSubpath()); |
There was a problem hiding this comment.
Actually, I was told that we were using the test suite incorrectly, and that we shouldn't compare the fields at all.
After berating me for even pointing out that there was an issue with the tests because these two tests introduced a different representation of the fields (original instead of canonical), they finally settled on changing the test suite so that all fields were original. At least there's an open pull request for that now.
So, either we'll end up having to remove everything except string comparison in our tests, or they'll finally settle on something. I am sort of against fixing the test suite locally in our copy, though, because we don't even know their intention.
There was a problem hiding this comment.
Actually, it was @jeremylong that submitted these tests upstream, so we can find out exactly what was intended with the fields. Was it a mistake or not? The tests don't pass with the current Java code and what do we do now about the fact that even after the "fix" in this pull request the Java code is failing the subpath comparison.
There was a problem hiding this comment.
Before continuing this one we may want to wait for the spec to be updated a bit - per comments like: package-url/purl-spec#409 (comment)
I know at least one of my changes to the test case is being reverted due to a misunderstanding/wording of the spec.
dwalluck
force-pushed
the
fix-parse-path
branch
from
c4171ea to
6a8f65a
Compare
dwalluck
changed the title
dwalluck
force-pushed
the
fix-parse-path
branch
from
6a8f65a to
801a012
Compare
|
Now that Spotless is there, there will be some conflicts. This should help: |
This change makes the two test pass that were introduced in package-url/purl-spec#368. See also package-url/purl-spec#404.
dwalluck
force-pushed
the
fix-parse-path
branch
from
801a012 to
d57cecb
Compare
This change makes the two test pass that were introduced in package-url/purl-spec#368.
See also package-url/purl-spec#404.