Images Invisible After use_ssl Flag is ticked


(edv4rd0) #1

This bug is a little weird. Basically images were working fine in 0.8.4. However, after my upgrade to 0.8.6 the use_ssl flag was ticked in setting although ssl isn’t set up. It caused some weird issues with images.

When viewing a post, the image url is prefixed with https: https://example.com/uploads/4/jsd7fsfsy8379.gif etc. But if you open the post to edit, the url is a plain http://example.com url. Why the discrepancy?

The second issue is that I unticked the use_ssl option and posted another image post. This time it was visible, but none of the others were. I went back to the main page and then entered the thread again and the url had become an https://eexample.com url but the use_ssl option was still disabled.

The third thing that may be relevant is in another old thread from before the upgrade there are two images which are visible whether the flag is on or off. However, when i upgraded I blew away the old discourse folder and had to manually copy these two images form the /tmp/discourse backup I had made.

All ownership and permissions on all images are the same.


(Jeff Atwood) #2

That option shouldn’t even do anything at this point. We have never tested https, I think it was mostly there as a reminder that we need to support it at some point in the near future…


(edv4rd0) #3

Okay, that’s good to know. What could be causing the images to to have https urls? I have it turned off at the moment and it’s still happening. The HTML image links are written and saved to the database at creation time, right? Or are we using javascript for this?


(Jeff Atwood) #4

I added the words (NOT IMPLEMENTED, EXPERIMENTAL) to the description of the use_ssl setting. @neil had talked about having an experimental flag for some of the site settings, but I think putting that ALL CAPS warning in the description probably suffices for now.


(edv4rd0) #5

Okay, I just updated to latest master, migrated the database, and removed the cache directory. New images are fine now, but old images still have a borked url. I guess it’s very low on the list really. I find it curious that the same image will have different (secure|non-secure) urls depending on whether you are viewing it in a thread, or in post-preview. Which looks like code to rewrite the url is implemented in two different places.


(Michael Brown) #6

This kind of ties into:

http://meta.discourse.org/t/scheme-independent-links-to-images-fail/5608

We ought to be inserting URLs referencing uploaded images to use the scheme-independent double-leading-slash format I mention above, not http:// or https://


(Jeff Atwood) #7

Now that we officially support https this is all resolved, right @sam? If so we can archive this.


(Sam Saffron) #8

I don’t there is a problem here, we use a CDN so are slightly off the config described. The prefixing is by design at the moment.

That said, we still don’t behave perfect when people move an old http site to https


(Jeff Atwood) #9