No UI guarding against dweb.link 504 Gateway Time-out

[bam80]

I've uploaded a file but eventually got error above by opening the link:
https://dweb.link/ipfs/bafybeieft247urh5buomrx5ejaghnhvkbqnpvyqkfho5b2ia3b4jqynfw4?filename=Screenshot_20210210_235026.png

Is it works at all?
FF 85.0

[lidel]

It sounds like you closed the tab before the file got propagated to public gateways.
Can you repeat the test?

[bam80]

No I didn't close the tab.
However, it works now.

[bam80]

Are there some logs left somewhere so we could debug why it didn't work yesterday?

[bam80]

Now I'm trying another file and got the same result - the link opening endlessly:
https://dweb.link/ipfs/bafybeihj6mw4snjdtdey3arvma2pys7ga7axo7k5g56yj53tbkqv7klkte?filename=Screenshot_20210121_235419.png

[lidel]

I think it could be a public gateway being overloaded at the moment.

You can take a look at browser Console or Network tab and see if preload call finished successfully (requests to *.preload.ipfs.io). If this fails or takes long time, dweb.link won't be able to find a provider for the data.

Usually its fast enough to not worry about it, but may get problematic on slow connections.

I think we could provide some UI that indicates the status of preload + tests availability at dweb.link via (HTTP HEAD request for each file) and until it is confirmed make those UI elements inactive.

I don't have bandwidth for this, but PR welcome.

[bam80]

Only now the second file loaded, so I uploaded a new one.

*.preload.ipfs.io is always returns OK (200).
The new file again shows 504 Gateway Time-out error after ~10min of trying.

I think it could be a public gateway being overloaded at the moment.

In this case you should be able to reproduce the issue?
Could you confirm?
https://dweb.link/ipfs/bafybeibg7l56pzxn6sqhwnixmx64vp2rpitvuzx5unhqeqnqkmpu3syjne?filename=Screenshot_20210120_154805.png

Usually its fast enough to not worry about it

It lasts for hours, so the experience is inappropriate here.

I don't have bandwidth for this, but PR welcome.

Unfortunately I don't have the needed experience.

[bam80]

I think it could be a public gateway being overloaded at the moment.

Could we probe different gateway in this case, or it's the best we can do already?

[lidel]

@bam80 for what its worth, your links load fine on my end :)

Are you behind The Great Firewall of China by any chance? In restrictive environments (or if you need more reliable solution than a public gateway) you and people you share data with may want to run Brave browser (or IPFS Desktop) with additional Companion browser extension enabled to ensure your local node is used instead of a public one.

[bam80]

Thanks, since few hours the links become working it seem.

Are you behind The Great Firewall of China by any chance?

No, but I'm behind my router, if it matters.
I'm still hoping to recommend this solution for people not able/willing to install any extra software..

see if preload call finished successfully (requests to *.preload.ipfs.io)

BTW, does it mean I don't need to keep the page open any more if the .preload POST requests return OK?

[bam80]

@lidel you was right, IPFS Desktop punched hole in upstream port of my router via UPnP, and it started working even for public gateways.
Any chance the same could be supported in js-ipfs?