Posting images broken?

Post Reply New Topic

On another thread, http://www.wrongplanet.net/postt222514.html, I tried to post some images and none of them appear. The url links work just fine.

Is the software broken with regards to image posting?

The only thing I can think of is that it refuses to accept certain valid characters in the image urls. If so, that certainly means that it is broken. I can't imagine why the software would refuse to accept valid urls.

It seems to work okay if I take the "?imgmax=800" off of the end of the url for the image.

When using the [img] BBCode tags the provided URL must start with "http://" (not "https://") and end with a filename of type jpg, png or gif.
In other words, only something which resolves directly and exclusively to an image filename will work.

Also, be aware that some sites will not permit direct linking to their content from another site so in a few cases, even otherwise valid image URLs may fail. Testing with a preview will confirm if that's the case.

While I'm here... please ensure that images are no larger than 800x600 otherwise they will be distorted by the forum software, because it fails to resize correctly when they are larger.

I've seen some sites that are real picky about http vs https for urls. If you paste a link with a https:// between url tags, their software doesn't recognize the https as being the protocol to use and so it provides an http. For example, (inserting spaces so that these don't get intterpreted as tags) "[ url ]https://www.wrongplanet.net[ /url ]" would become "[ url ]http://https://www.wrongplanet.net[ /url ]" which clearly won't work.

One time I posted an image that was larger than 800x600 and someone edited the tag to resize the image. I don't remember how that modification worked.

In my case, I use the Opera browser. If too large an image causes a problem, I just click the "Fit to Width" button and Opera usually adjusts everything to make it show up properly.

Thanks.

The thing with https being used inside the [img] tags is a local, forum software issue - I assume the code behind those tags is "a bear of very little brain" and simply not written to handle https image links. (actually, it's just the same with the [youtube] tags too)
Generally - or with images/YouTube videos anyway, what's available from https is also available from http so usually a small edit to the URL fixes things.

The forum's image resizing adds an extra sizing parameter immediately after the opening [img] tag which would rescale it correctly, but the code messes up the calculations.
It takes the form

On those image threads I have an interest in I often tweak the numbers to correct the scaling. It annoys to see those images distorted!
To calculate them, I get the original image dimensions and divide the longest edge by 800 and then divide the other edge by that result, yielding either [800:xxx] or [xxx:800]
So given an image of 1024x768: 1024/800=1.28 and 768/1.28=600 - giving the additional tag of [800:600] and preserving the aspect ratio.
Likewise, an image 1536x960 works out as [800:500] - aspect ratio unchanged.
The default, auto-calculated result would be [800:960] which results in a badly distorted aspect ratio.

It's not so much that the image might be too large for the browser (and Firefox also auto-fits an image to the browser window size), more that the image will be displayed incorrectly in the thread.
Clicking the image opens it in another window and it's there that the browser adjusts the size, so it works out Ok using that approach.
I just prefer to see it displayed correctly in the first place...

That's basically what I did to scale an image down the one time I noticed it happen with one of my images.

The Opera browser is clever enough to proportionally reduce the image size to nearly always make everything fit nicely in the window. So an extra large image for me isn't really a bother.

throwing an https object into an http page is a violation of web standards, and usually the browser will throw a "mixed content" error to make sure the user is aware of what they are doing. Thus, software that allows users to embed objects will force http on http-served sites, and do any number of things on an ssl-secured site.

I don't see why it would matter to load objects using the https protocol in a web page using the http protocol. The other way around would certainly be a concern, though.

That said, I use Opera which I think doesn't complain about it at all anyway.

Both are a concern to your browser because it has no way of knowing what the object is or why it's encrypted.

Do you know which RFC covers the standards regarding mixed content?

RFCs don't apply because they only define the individual protocols used for the requests (HTTP and HTTPS). Security concerns arrising from use of mixed connection types is out-of-scope of the protocol definitions themselves.

Where are the internet standards for the mixed content published, then?

They aren't standardized - the implications for mixing secure and non-secure content is specific to each browser and how they handle the interaction. Some things, such as cookie re-use, are common to most (if not all) browsers. Some things are specific to certain browsers (IE at one point would execute JS code on an iframe in the same sandbox as the main site content - which could lead to some "unexpected" things happening to supposedly secure POST variables)

That makes sense, then. The Opera browser is supposed follow the standards better than just about any other browser. I'd think if there were standards on this, then Opera would quickly implement them.

The mixed content error appears to be mainly in Internet Explorer. Everything I've found in the last few minutes on the issue discusses providing content using the http protocol on a page served with the https protocol. So far I haven't found anything about it going the other way.

Logically, serving content over an encrypted link for a page that is not encrypted shouldn't present a problem.

I may set up a little test and see what happens. All I need is an image that I can display with an https link and put it in an http page on my web site.

If you have an HTTP application that uses cookies, and you use HTTPS to encrypt "sensitive" parts of the application - the data is encrypted, but the cookie can still be sniffed and the session spoofed.

If you have an HTTPS application with a single HTTP element (even a picture) - the cookies are still sent in the request header, which can again be sniffed and replayed to spoof the session.

That is the most common problem with mixed content, but there are others - depending on how the logic in the browsers handles things. You can't standardize how browsers implement functionality - otherwise there would be literally 0 difference between browsers. You define as standards functionality that needs to be standardized to make the web work (HTML, CSS, etc) - but leave the browsers autonomy to decide *how* to implement that functionality.

I created a test web page (actually copied a web page for something different from my site) and replaced the thumbnail image of the local church with an image for of a woman and her two dogs that was served with https.

I tested it with Opera, Firefox, Chrome, Konquerer, and Epiphany on my SuSE Linux workstation and with Internet Explorer on a Windows 2000 system.

Both Opera and Epiphany showed the image without a problem.

Firefox and Chrome both failed to show the image.

Konquerer failed to show the image and gave an error message message in a popup.

Internet Explorer gave the expected warning messages and asked if I wanted to continue. When I continued, it displayed it correctly.

So I can now see why Wrong Planet and other sites do not permit https images to be linked in.

Thanks for the information. It has been quite useful.