Posted: 5/14/2015 11:59:06 PM EDT
|
It seems you guys are lopping off the protocol portion of the image url on the new resized clickable images (which I loathe by the way).
For example this post: http://www.ar15.com/forums/t_1_5/1726771_ATTENTION_All_Top_Gear_fanboys__Clarkson_suspended.html&page=15#i52793911 If you quote you can clearly see http is specified: https://www.ar15.com/forums/manageReply.html?a=quote&b=1&f=5&t=1726771&r=52793911&page=15 But in HTML you get:
This presents a real problem when the image is hosted ONLY on HTTP, but you're browsing Arfcom on HTTPS. The image will then fail to load. You can also see youtube videos are similarly broken. For Youtube since Youtube supports HTTPS, you should ALWAYS use the HTTPS URL so that when people are browsing this site on HTTPS the videos will still work. And the HTTP users will still get the transit security and assurance of the right destination host for their Youtube videos. |
|
post in this thread and reference this one please dont post 87 inch wide code |
|
While running HTTPS you are expecting a secure site. Allowing unsecured content presents a problem. We are moving to ensure SSL is as secure as possible while using the site. At this time we're locking down 3rd party content.
Please keep in mind that when the protocol is removed from the link, your browser will demand the page in its preferred format. This means your browser is asking for a secure page because that's what it wants. We allow HTTPS links for http surfers, but not the reverse. |
|
If you're trying to fix insecure content warnings (ie Chrome's yellow warning) you should change the protocol on the avatars, and various images around the homepage and everything else which explicitly reference HTTP even when served over HTTPS... (Fake HSTS header/HTTPS Everywhere fix those anyway), But I think you're missing the point. There really isn't any reason to fix an insecure content warning when there is an expectation of user generated content which will reference insecure content.
Expecting a "secure site" as you stated means you're expecting the traffic to the domain in the URL (ie "www.ar15.com") to be 1) the real server 2) unsniffable and 3) untamperable. Ie my auth request, my auth cookies, my posts, my messages, etc, all that stays protected so no one can read them or inject ads or malicious scripts on to my page. You also expect all scripts loaded by the page are of course also HTTPS as well (ie Chrome's red warning if they're not), for many of the same reasons, any script that the site loads if they are injectable you basically lose all of the above as someone clever enough can script the collection of anything in the DOM. The static "media" assets that are not hosted on that domain like images often posted by users are not necessarily going to have the same guarantee and there is no expectation for them to be. They're static assets at a specific location which may or may not support SSL and of course may or may not display the same content when reaching the HTTPS endpoint if it exists. On HTTP referenced assets at most the worse that can happen to me is someone in the middle can swap out images and of course anyone watching traffic can see the asset and the relative URI of the asset. Not typically a big deal, they already see the domain it's hosted on via the IP or with the SNI piece depending on TLS version (Or in the CONNECT request with an HTTP Proxy as typical for corporate environments), hiding the relative uri on what is most likely going to be an image host doesn't seem to buy much imho. The ONLY right way around that and the insecure content issue (which seems to be your definition of a "secure site") would be cache everything and do the GMail approach where all referenced assets are just cached by the server and served that way, which I'm not in favor of (and I'm sure arfcom isn't really either, it's a tricky and somewhat costly endeavor for little gain). Anyway, it is what it is. |
|
Quoted:
Ok, so how do I get the images to show? It is insanely frustrating to see blank images 75-80% of the time. Why should someone have to work to enjoy a website? The only way is manually copying and pasting the image URL and changing the protocol back to http. The protocol information supplied is being intentionally stripped before being returned to the browser 
|