darkoshi | photos from this year

You're viewing

darkoshi's journal
Create a Dreamwidth Account Learn More

Reload page in style: site light

March: Dogwood blossoms

April: Some kinda plant

May: Hydrangea blossoms

July: Little plastic caps for covering the pins of LED tubes

August...

Downtown Columbia

Sunset & cloud

Tree stump with fungi

Hey, wait a minute. Why, when I right-click one of the photos in this post and select to view the image, does it bring up a Dreamwidth URL? Is DW automatically copying photos that we post, to the DW servers? It didn't used to do that.

Flat | Top-Level Comments Only

The post and comment Frith linked to indicate that Dreamwidth set up a proxy for images whose URLs use HTTP instead of HTTPS, as otherwise browsers would give users a mixed content warning when loading the HTTPS Dreamwidth page which included the HTTP images. This proxy has been there for over 2 years; I'm surprised I didn't notice it before now.

But how that proxy is implemented, and if DW caches the images, or how often it checks if the image has changed at the original URL, I'm not clear.

I noticed this all to begin with because I missed uploading one of the images that I linked to. My post preview showed a broken image icon. That is when I checked the image URL and found it had a DW URL instead of my original image URL. Then I uploaded the image, but my post still showed the broken image icon... so I think there must be some caching being done. I forget how I fixed it; I either had to re-open the page, or re-save my post (which when I edit it now, still displays the original URLs BTW).

2) I hadn't thought about that. Interesting thought. I was initially concerned whether DW would still keep copies of images on its servers after I deleted them from the original location. That is something I'd like to have control over. Having DW keep its own copies could be a good thing, to keep images from breaking when my image hosting goes down. Or a bad thing, if I wanted to remove the images on purpose. But at least now I know that if I host my images via HTTPS instead of HTTP, then the proxy shouldn't end up being used anyway. I put it on my To-Do list to research how to do the latter, but it's not a priority for me. Maybe someday.

I forget how I fixed it; I either had to re-open the page, or re-save my post (which when I edit it now, still displays the original URLs BTW).

*bug eyes on bit in parentheses*

That's a bit...strange. Thanks for the warning, as I use WP as my external host for most, though not all, images.

2) Would caching necessitate or imply the copy DW stores is permanently kept/doesn't expire? Asking because I'm thinking of browser caching, in which the page can be set to expire after a certain amount of time (instantly/hours/days/never) so at that point must be refreshed to retrieve the latest copy. Could it work the same way for images, in which case DW's copy would, if set to do so, just go *poof* at some point (deleted/no more copy)?

Does DW keep cache in general, I wonder? So I make a new post and edit it 25 times after posting it; does DW retain any/all prior versions (actually, I've always wanted to know this)? No biggie if you don't know, just wondering.

As to 2), I wonder if there are any tools that could help from the client side to find out. The name of one's just slipping my mind but lets you look deep behind the scenes (not Web Inspector, it's like...grinding my gears here but can't think of its name. But it's an all-caps acronym with just four letters).

Cached items do usually expire after a certain amount of time, or after some other limit is reached (number of files, amount of space used).

It's possible that what I experienced was affected by browser caching. But since it was a problem of an image not being loaded at all, rather than an old version of the image being shown, it seems unlikely (there was nothing for the browser to cache).

> So I make a new post and edit it 25 times after posting it; does DW retain any/all prior versions (actually, I've always wanted to know this)?

Keeping multiple copies of each post would increase storage space a lot, so I doubt it. I have wondered, when one deletes a post, if it is actually deleted, or only marked as deleted and then no longer shown. But since I haven't heard of there being an undelete function available, there wouldn't be any reason for it to be kept either.

If DW is caching on their server side, I don't think client side tools could help determine much. But you could upload an image, link it in a post, then update the image and keep checking back to see how long it takes for the post to show the new image. That still wouldn't tell you though if the caching was time-limited or otherwise.

That still wouldn't tell you though if the caching was time-limited or otherwise.

You can't check the header for that, then? As it's image-specific, which isn't tied to header info on cache expiry, I guess? You don't need very special tools for that, anyhow. The one I'm thinking of (the 4-letter acronym) is pretty all-purpose but maybe can't look into that, either (if I ever think of its name I'll look it up again just to see what its limitations are).

I have wondered, when one deletes a post, if it is actually deleted, or only marked as deleted and then no longer shown.

I think (and this is just a feeling/instinct I've always had; no other basis) they think it's deleted but it's not. So the latter, basically.

There's no undelete button because a) they think it's gone, honestly and b) even if it wasn't it's a Cost thing - mainly it'd mean extra churn on servers to restore things (we'd probably all do it at least once in a while for Reasons, even just silly ones) so maybe not something they'd implement even if they could.

Pure speculation on my part of course, on all of it.

Edited (typos) Date: 2019-09-06 05:04 am (UTC)

In Firefox, you can open Tools - Web Developer - Network. Then open or refresh the page you're interested in that same tab. It will list all the requests sent to fetch the data to display for that page, including the images. When you select one of the entries, it will display details for that request & response, including the headers.

For the images on this page, I see response headers including "x-cache: Miss from cloudfront" or "x-cache: Hit from cloudfront". I'm not sure if that is related to the Dreamwidth image proxy or something else.