Photobucket

[karzilla]

Thanks to everyone who let us know that Photobucket images were not loading properly on some pages. The problem seemed to be mostly limited to HTTPS requests; Dreamwidth maintains a list of known high-traffic image sites that support HTTPS, so that our secure content proxy service doesn't cache them unnecessarily. Unfortunately Photobucket seems to have recently changed their site configuration such that HTTPS requests aren't being served as expected, and we've now taken it out of our list of "proxy-exempt" sites.

If you continue to have issues, make sure you're not using HTTPS Photobucket links. It's a bit counterintuitive, but if you use HTTP instead, it will be automatically transformed on our end to an HTTPS link that uses p.dreamwidth.org.

Hope that clears everything up for now! Let us know if it doesn't...

Comments

[tinny]

Unrelated to photobucket, but could you explain what you mean by

it will be automatically transformed on our end to an HTTPS link that uses p.dreamwidth.org

? I have seen that some of the image links in my posts (hosted on lj) are also prefaced with p.dreamwidth.org, and wondered what it means.

[denise]

Basically: You can't load insecure content (via HTTP) on a page (such as your reading page) that's accessed via HTTPS without your browser complaining vigorously (or, in some cases, just refusing to load things), because mixing secure and insecure content on the same page makes the secure content insecure. So we have two options if we want to let people use HTTPS to access the site: either we don't let people use images in entries, etc, that are loaded via HTTP (impractical), or somehow make images that load via HTTP into images that will load via HTTPS.

Since not every site on the internet supports HTTPS yet, we can't just automatically rewrite "http://blah" in image tags to "https://blah": it would fail too often. So instead, if an image tag uses the http://blah form, our image proxy (that's what the p stands for) muscles its way in between your browser (asking for the image via HTTPS) and the remote server (serving the image via HTTP), takes the image, and serves it via HTTPS.

It's basically "putting a brown paper wrapper around the magazine so people can't read it while it's in the mail", more or less. :)

[tinny]

Ah, and since LJ turned off https in December, it now falls in that category. :/

Thank you for the good explanation!

[denise]

Actually, LJ never offered HTTPS access to journals/Scrapbook images in the first place! (Probably because they didn't want to have to solve the mixed-content problem. Our solution is ... well, not hacky, it's actually nicely elegant, but it's a bit of a pain and requires increased bandwidth/disk space usage.) So we've always proxied images that were being loaded from people's Scrapbook accounts.