Public purldb API appears to ignore subpaths when submitted as part of a URL

[johnmhoran]

It looks like the public purldDB API responds to the inclusion of a # subpath separator followed by the subpath value by ignoring the subpath. An example: in the public API, https://public.purldb.io/api/packages/?purl=pkg:maven/org.elasticsearch/elasticsearch@7.17.9#fake/subpath returns the same 2 records returned by https://public.purldb.io/api/packages/?purl=pkg:maven/org.elasticsearch/elasticsearch@7.17.9 -- the only difference is the presence or absence of #fake/subpath.

I understand that this might be an encoding issue, but note that according to the purl specification, "the '#', '?', '@' and ':' characters must NOT be encoded when used as separators. They may need to be encoded elsewhere" and a bullet further below: "the '#' subpath separator must be encoded as %23 elsewhere". Perhaps the documentation needs to be clarified?

[johnmhoran]

Encoding the subpath separator returns 0 records, which makes sense since I understand the DB has no purls with a subpath. https://public.purldb.io/api/packages/?purl=pkg:maven/org.elasticsearch/elasticsearch@7.17.9%23fake/subpath

[Mahi-272006]

@johnmhoran
From the description, it seems that the '#' character in the PURL is treated as a URL fragment and therefore not sent to the server in API requests. Encoding it as '%23' allows the server to receive the subpath.

I would like to work on this ...please assign this issue to me.