bug: ambiguity about tar/car request pathing support

[SgtPooki]

I’m looking at https://specs.ipfs.tech/http-gateways/path-gateway/#accept-request-header and thinking about recent verified-fetch changes.

For vnd.ipld.car and x-tar requests to the gateway, are paths expected to be supported? i.e. can I request a tar/car for bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze/58wiki/6F or QmSnuWmxptJZdLJpKRarxBMS2Ju2oANVrgbr2xWbie9b2D/albums instead of having to resolve the CID of the content at that path myself and then requesting that resolved CIDs content?

[lidel]

TAR and CAR are separate response types with different behaviors.

• CAR responses are trustless, so to be able to verify end-to-end (from root CID to final terminating filename) response always includes extra blocks that allow walking the parents
  • see dag-scope:

    Describes the shape of the DAG fetched the terminus of the specified path whose blocks are included in the returned CAR file after the blocks required to traverse path segments.

• TAR responses are deserialized, so they only include the file or directory at terminating segment

[lidel]

I think the fix here is to clarify CAR in https://specs.ipfs.tech/http-gateways/path-gateway/#accept-request-header to include the same note as we have in dag-scope + make TAR more explicit that we mean root of terminus element

Filled:

• docs(gateway) clarify scope of blocks in car responses #489