Comment by rzzzt
1 day ago
Are clients permitted/expected/tolerated to run off and fetch the contents of image links for inline display, once a page containing such links is retrieved?
1 day ago
Are clients permitted/expected/tolerated to run off and fetch the contents of image links for inline display, once a page containing such links is retrieved?
Permitted? Technically, it can't be stopped (well, it kind of can, see "Tolerated?").
Expected? No, it's counter to the intentions of the community.
Tolerated? Maybe. Here's a fun one (saw this in one of the past discussions dang linked): https://github.com/makew0rld/amfora/issues/199. That was over favicons, but the response would be similar if linked images were automatically fetched. Though the protocol has a "backoff" return code that could be used to throttle those things that would be less disruptive than Drew's approach of banning specific clients.
They are not supposed to do that, but some clients have an option to enable it anyway.
There are also clients that make a second request to ask for a favicon. In the spirit of the protocol the "icon" is just a UTF-8 symbol, but that behaviour is still controversial.
Only if the page is inside of a ZIP archive stored on the local computer and only if the link is to a picture within the same ZIP archive. (However, it would be good to have an option to disable inline display even in that case.)
This would be my preferred way of document distribution. Images and video is allowed, but they have to be part of the same document as the text. Everything is in the same zstd'd tarball. No separate roundtrips for fetching images. Either you download the document or you don't. Would be cool with some limitations on overall document size as well.
Not really, in fact they're forbidden - those clients are spec-uncompliant.