Avatar of IKtech
 asked on

JPEG Images Being Copied to Root with Garbled File Names on IIS7 Web Server

What is happening is that whenever our website tries to load a JPEG file from a non-local source (another website for instance), it appears fine in the raw html but when the page is displayed in a web browser the file name changes from 'http://www.website.com/image.jpg' to '/0ac5dd22599c9a2e9ced06e1aaee901f.jpg'.  The file name is always different, but is always a long string of characters like that.  It loses whatever web address it had and appears like that.  At the same time it creates a copy of the image of the root directory of the server drive (C:\) with the same file name.  Of course since the website proper only sees what is in its folder (C:\inetpub\wwwroot\) it can't see any of those files and just displays a broken image.

So what we know is:
- We are using IIS 7 for the web server.
- It only affects JPEGs.
- It only appears to affect non-local sources. Locally hosted JPEGs inside the wwwroot folder display fine.
- The same JPEGs work fine when tested on another web server.
- The other web server is a clone of the affected one, yet performs normally.

We are about to toss this one in the pile of Great Mysteries along with 'Bigfoot' and 'Why People Liked Achey Breaky Heart', so any and all ideas are welcome and we thank you in advance.
Microsoft IIS Web ServerWeb DevelopmentWeb Servers

Avatar of undefined
Last Comment
Dave Baldwin

8/22/2022 - Mon
Dave Baldwin

That is far too vague and web sites do not copy images.  Programs do.  And clearly the other web server is not an exact clone since it does not act the same.

How are you loading and copying the images?
David Johnson, CD

the devil is in the details

The images are being linked using HTML <img> tags on web pages. The Source for those <img> tags are for images hosted on other sites, but we somehow are ending up with the image file - with a different gibberish file name - saved on the server.

Most of the images seem to be connected with a Wordpress plugin that imports posts from an external provider. However, the HTML doesn't have anything special about it.  It's just an <IMG> tag for all these images with a width of 100%.  Also, the back up server has the identical plugin running and does not have this issue.  A small number of the images were actually uploaded using the Wordpress upload media function, and would appear fine in previews but when the post was published would become broken images with a gibberish name, and the image file with the gibberish name would appear in the root folder.

And yes, while certainly it is evident that there is some clear difference in how the two servers are operating, they both have the same identical settings (we have triple checked while investigating the issue) and the second server was created as a copy of the main one.

The problem is two fold:  the URLs for these <img> tag sources are changing between being saved and being viewed as a web page somehow, and then the image files are appearing in the root directory of server drive, outside of the public web folder and the website root folder (Hence why we suspected IIS would be the culprit and not Wordpress).  But we cannot find anything on how another case of this happening, and quite honestly are very baffled on how it can actually happen because as you have said - images are not supposed to be copied.  Yet here we are, with a copy of external images that have been linked appearing on our servers.

The devil may be in the details, but we haven't the foggiest on where we would even start looking for the culprit causing this mayhem.  Is there anything with IIS that handles how external image links are displayed for instance?
Your help has saved me hundreds of hours of internet surfing.
Dave Baldwin

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.