Spec/test mismatch

[achingbrain]

This test is executed as:

GET UnixFS with 'Accept: application/json' (not dag-json) is no-op (no conversion)

The CID used in the test is a RAW codec CID, bafkreialihlqnf5uwo4byh4n3cmwlntwqzxxs2fg5vanqdi3d7tb2l5xkm, that resolves to this block.

The test:

1. Requests a RAW codec CID
2. Sends an Accept: application/json header
3. Expects a Content-Type: text/plain response header
4. Asserts that the body is the raw block

The spec says of Accept: application/json:

application/json – same as application/vnd.ipld.dag-json, unless the CID’s codec already is json (0x0200). Then, the raw JSON block can be returned as-is without any conversion.

The CID's codec is not JSON, so we refer to the application/vnd.ipld.dag-json Accept header:

application/vnd.ipld.dag-json – requests IPLD Data Model representation serialized into DAG-JSON format. If the requested CID already has dag-json (0x0129) codec, data is validated as DAG-JSON before being returned as-is. Invalid DAG-JSON produces HTTP Error 500.

The CID codec is RAW, so it's an opaque block of bytes and we don't validate it as DAG-JSON. The IPLD Data Model representation of a byte array as JSON is { "/": { "bytes": "...base64" } } but the test is expecting the raw block content with a content type not in the accept header.

The test seems to want us to:

1. Ignore the Accept header
2. Use mime-type sniffing to determine the returned content type?

This doesn't seem to follow the spec, or am I missing something?

Related: #200

[lidel]

Hm.. the specific test (GET UnixFS with 'Accept: application/json' (not dag-json) is no-op (no conversion)) and the RAW codec CID (bafkreialihlqnf5uwo4byh4n3cmwlntwqzxxs2fg5vanqdi3d7tb2l5xkm) were removed in #254 (IPIP-524, v0.10.0).

Cross-codec conversions are no longer expected by the conformance suite. Requesting a format that doesn't match the block's native codec now returns 406 Not Acceptable (TestCodecMismatchReturns406). The remaining TestPlainCodec and TestNativeDag tests only request formats matching the CID's codec.

So.. @achingbrain is there anything remaining to be done I missed here or can this be closed?