Paths with # not handled as expected #83
Description
This one might be a bit subtle, and perhaps there's room for some discussion here but here's a discrepancy between how Lassie thinks of a traversal vs how freeway does.
Consider the CID+path currently with the most errors recorded for our "extraneous blocks in CAR" error coming out of freeway: bafybeifcomhxkhspd6imbfl726cfzfrfk6ooma5gvr6vdohmo3aa5biscm/#13 Orias.
It looks like a name anchor in a URL, but it's been provided to us as a path and we're interpreting it as such. Likely there's an error somewhere up the chain, perhaps all the way to the browser, or maybe in the encoded page the user is navigating from and through the gateway, but that's a separate issue.
lassie fetch 'bafybeifcomhxkhspd6imbfl726cfzfrfk6ooma5gvr6vdohmo3aa5biscm/#13 Orias' will yield just a single block, because it wants to use that block to find the next segment, #13 Orias, but one doesn't exist, because the referenced CID is a sharded file. So all you get back is a single block, no more, and it's technically an error for the user because their query couldn't be fulfilled (currently debating exactly what to do with unfulfillable paths here but that's a separate issue again).
But freeway deals with this differently:
curl -v -H 'Accept: application/vnd.ipld.car;version=1;order=dfs;dups
=y' 'https://dag.w3s.link:443/ipfs/bafybeifcomhxkhspd6imbfl726cfzfrfk6ooma5gvr6vdohmo3aa5biscm/%2313%20Orias?dag-scope=entity' -o bafybeifcomhxkhspd6imbfl726cfzfrfk6ooma5gvr6vdohmo3aa5biscm_w3s.car
yields a CAR with 21 blocks that I think form a full sharded file. So I guess freeway is either stripping off the # at some point, or doing a best-guess select-all when it gets to a terminal rather than attempting to go further and failing early with the single block that doesn't provide a path to the next path segment.
Error logs through Rhea have a ton of these, but most of them seem to have email addresses in them so I'll refrain from pasting in here.