HTTP gateway returns 0 bytes, ipfs cat returns proper file.

[TheDiscordian]

Version information:

go-ipfs version: 0.7.0-ea77213e3
Repo version: 10
System version: amd64/linux
Golang version: go1.15.2

Description:

Hello. I've recently tried adding ~19k files (2GB) to IPFS/MFS via the files write command. It seemed to work well, and ipfs cat can return the files correctly. However when using IPFS Companion, many files show the size of "-", although the total directory size is correct. At this point, I verified my blocks, and my pins. Several thousands pins returned errors, so I removed all the erroring pins. I've since updated the directory to get a new CID, and updated IPNS (and pins). I still have the issue of the HTTP gateways returning 0 bytes though.

The directory in question is located here:

http://portal.thedisco.zone/osrs/index.html
/ipns/portal.thedisco.zone/osrs/index.html
/ipfs/QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24

Some files seem to work fine, but most don't. I'm using index.html as an example there, as that's the first file you'd see. To reiterate the issue:

Running ipfs cat QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24 returns the expected HTML page, even on an external node I just setup. However attempting to view that file through a gateway, doing something like https://ipfs.io/ipfs/QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24 will return 0 bytes.

As I'm quite new here, I'm not sure why the HTTP gateway, and using IPFS directly are so different. The galacteek browser handles the pages just fine, but I'm assuming that doesn't use the regular HTTP gateway over port 8080.

Edit: FWIW, I tried ipfs get (which I've never used, I just use cat), and I immediately get:

user@localhost:~/ipfs/go-ipfs$ ./ipfs get QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24 -o index.html
Saving file(s) to index.html
 0 B / ? [--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=] 0s
Error: archive/tar: write too long

[aschmahmann]

@TheDiscordian did you add that file into IPFS or fetch it from somewhere else? If you added it what parameters did you use to ipfs add? For context doing ipfs cat QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24 > ipfs add gives me a different CID (QmcHrWufx7N7HsYnio61eMQKZ92SyYqsVgABGRRkShTd7f).

Somehow it looks like you have a UnixFS node which has the Type field as Raw (instead of something else like FIle) and yet has links in it (https://explore.ipld.io/#/explore/QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24). @Stebalien @rvagg does this seem valid to you?

[TheDiscordian]

Perhaps to offer more clarity, I used ipfs-sync to add the files. So to add that file, it'd run AddFile, which runs files/write?arg=%s&create=true&truncate=true&parents=true, where %s is the MFS destination of the file. Then the file contents are sent over, with a header added via req.Header.Add("Content-Type", writer.FormDataContentType()). After this it just pins the root directory, and updates IPNS.

[Stebalien]

Somehow it looks like you have a UnixFS node which has the Type field as Raw (instead of something else like FIle) and yet has links in it. @Stebalien @rvagg does this seem valid to you?

It's not. I wonder if this is a bug in MFS?

[Stebalien]

Yeah, this is a bug in the trickle-dag code.

[TheDiscordian]

Awesome, do you guys need anything else from me at all? Itching to remove this mess from my MFS and try to get the directory working correctly.

Additionally, any idea on the cause? Did I hammer the MFS too quickly?

[Stebalien]

No, it looks like there's just a bug in MFS. Basically: 1. We create an empty file with type RAW. 2. We then add chunks to this RAW node. At that point, we'd need to convert it into a node with type FILE but we don't.

[coryschwartz]

Is this still an issue since ipfs/go-unixfs#88 is merged?

[RubenKelevra]

@Stebalien might this be related to #6936?

[lidel]

I did some related tests with 0.9.0-rc2 and was not able to replicate the "HTTP gateway returns 0 bytes" error with new data.

I found weird DAG layout, but the file loads fine via gateway (details in #6936 (comment)), so assuming this one got fixed sometime between 0.8.0 and 0.9.0-rc2.

I was not able to create a dag-pb file of a raw type, but if I reuse the problematic block from OP:

ipfs files cp /ipfs/QmasYd9docsEaozsdZxCp29yfoZoUJDrvqgkT8Hry66N24 /raw-dag-pb-type

and then execute truncating writes against it a few times:

echo "hello world" |  ipfs files write --create --parents --truncate --raw-leaves --cid-version 1 /raw-dag-pb-type

...the produced root CID is.. CIDv0 (QmZFh82ULMNqbwtux6C1kZfetsY8ciJHRgMqNyv9dLGQMQ) with dag-pb subtype "raw" and weird DAG layout that includes CIDv1 raw leaves:

I confirmed that the "raw dab-pg" CID:

• loads fine via localhost gateway provided by go-ipfs 0.9.0-rc2
• returns 0 bytes when loaded via go-ipfs 0.8.0

@RubenKelevra I'm closing this (as the "HTTP gateway returns 0 bytes" bug seems to be fixed in 0.9.0-rc2), but we need to figure out the messy DAG layouts produced by ipfs files write --truncate --raw-leaves --cid-version 1 – this is continued in #6936