karzilla: a green fist above the word SMASH! (Default)
Karzilla, Destroyer of Bugs ([staff profile] karzilla) wrote in [site community profile] dw_maintenance2017-03-17 02:41 pm

Photobucket

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...
sparkythegeek: (WH - HG hands behind head)

[personal profile] sparkythegeek 2017-03-17 08:55 pm (UTC)(link)
Hahaha, and here I've been "hollering" at PB on their support and plus payment email, insisting they'd broken something! :o) Oopsie...

Glad it's working again!
sparkythegeek: (Tink in Fairyland)

[personal profile] sparkythegeek 2017-03-18 12:42 am (UTC)(link)
LOL, well, that's fair! :)
ranunculus: (Default)

[personal profile] ranunculus 2017-03-18 05:01 am (UTC)(link)
As a beta user (way back in the day) of Photobucket I'm absolutely sure they "broke something". Plus introduced it without announcement.
Plus introduced code sure to NOT work with any Linux based program. That's why I finally got a Smugmug account which works beautifully with DW.
killerweasel: (pearls joy)

[personal profile] killerweasel 2017-03-17 11:10 pm (UTC)(link)
Photobucket has been having tons of issues the last few days, so I assumed this was a problem on their end. And it sortof is. I just checked and all of the images that didn't show up previously are showing up again. That's great because I have 12 years of images (16,000+) that were transferred over here from livejournal.

Thank you! :)
Edited 2017-03-17 23:11 (UTC)
lilly_c: (Default)

[personal profile] lilly_c 2017-03-18 09:47 am (UTC)(link)
Photobucket seems to be working just now.
fillefidele: (Default)

[personal profile] fillefidele 2017-03-18 10:27 am (UTC)(link)
Just jumping on in to say I am working on copying over bios today (Jo first, whatevs) and I'm not experiencing any problems so far. I was confused as fuck to see entries appear from ij though XD
mapsedge: Me at Stone Bridge Coffee House (Default)

[personal profile] mapsedge 2017-03-20 01:56 am (UTC)(link)
One wonders if you could use the method Google uses for analytics links and put in your links like this:

//mydomain.com/someimage.jpg

leave off the protocol and let the browser decide.
mapsedge: Me at Stone Bridge Coffee House (Default)

[personal profile] mapsedge 2017-03-20 03:19 am (UTC)(link)
Of course! I typed faster than my brain could think about it. I hoped no one would notice :-/
Edited 2017-03-20 03:20 (UTC)
frith: Violet unicorn cartoon pony with a blue mane (FIM Twilight read)

HTTPS Related!

[personal profile] frith 2017-03-21 01:14 am (UTC)(link)
[personal profile] tornir gave me a heads-up on this last week, but for Flickr and a Ponycountdown widget. Long story short, I reuse old embedded images for events, such as the February 6 Harmony Day. The old image is sourced from a http URL, so it gets cached as an https p.dreamwidth URL. That works out fine for the Flickr images, but not the Ponycountdown widget in the community sticky. The widget was also using http urls. I didn't see the difference because I don't require my browser to use https, but for [personal profile] tornir, the countdown was not counting down.

The solution: swap in https in the html for the widget at both instances where http was being used for an URL.

Now the widget works for everypony. 8^)
frith: Violet unicorn cartoon pony with a blue mane (FIM Twilight friendly)

Re: HTTPS Related!

[personal profile] frith 2017-03-21 11:13 pm (UTC)(link)
You're welcome. ^_^
pjcatsinthetardis: (Default)

[personal profile] pjcatsinthetardis 2017-03-21 07:15 pm (UTC)(link)
Photobucket was also down at the time of this post...it was down for 3 days...may have contibuted to the issue.
koka_lermont: (Default)

[personal profile] koka_lermont 2017-04-14 03:20 am (UTC)(link)
Мне френды пишут, что мои фотографии не видно.как исправить ошибку?
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-04-14 03:25 am (UTC)(link)
I'm so sorry, but we only speak English, so I can't write back to you in Russian!

I see your pictures in most of your entries. Do you mean this entry: https://koka-lermont.dreamwidth.org/3999727.html ?

If you look at the source of that entry, the <img> tag is wrong. Edit the entry and correct it.
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-04-14 03:55 am (UTC)(link)

You're welcome!

tinny: (__geek ifruity)

[personal profile] tinny 2017-04-16 03:26 pm (UTC)(link)
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: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-04-17 05:41 am (UTC)(link)
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: (__geek ifruity)

[personal profile] tinny 2017-04-17 07:43 am (UTC)(link)
Ah, and since LJ turned off https in December, it now falls in that category. :/

Thank you for the good explanation!
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-04-17 08:24 am (UTC)(link)

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.