Images on Web Site

[GatorsFan]

I ran across a rare issue with Linux and images on one particular web site - the web site loads and comes up but no images are displayed - So I though well try a different browser - nope - try tuning off all add-ons - Nope did not work either - So I booted Windows 11 in VirtualBox and it worked - So I installed an Agent Switcher on Firefox and Brave browers

for Brave Browser I installed - User-Agent Switcher & Manager Pro from Tiny Convert

User-Agent Switcher & Manager Pro - Chrome Web Store

User-Agent switcher with Client Hints & navigator. Spoof, rotate & manage identities per-tab or per-domain with profiles.

chromewebstore.google.com

And selected Chrome 124 & Windows 11 and the images were there

The website in question was https://growhoss.com/ a gardening and seed store - I was just curious if anyone else had this issue on this or any other web site??

So I came to the conclusion there images are using the exact capitalization of the Linux file system which is required for images. Windows is not case-sensitive, so mismatches is no big deal with won't affect the server's ability to locate the file properly. But, with Linux, folder and file name differ by case sensitivity and will not display - web master laziness I believe

 

[Trml]

The capitalization does not matter, in no way and in no direction. What would matter is if the html they serve references a wrong image file name to show. In this case, you would not see an image by spoofing the user-agent.

The reason probably is, that they (the garden shop) or their provider have some network firewall to block bots and that is misconfigured. It happens. Linux is not so widely used, so it can slip through testing easier, I guess.

There are some instances where companies deliberately discriminate users by filtering browser agents, more regularly it is geoblocking. A known example is Apple, they blocked requests by "apple foreign" user-agents to their maps service for a while. Other examples that still block are in the first post of https://github.com/whatwg/html/issues/10518

 

[KGIII]

I have issues with it. I also have said extension installed -- but on a different computer. I can test that later, if you'd like.

The capitalization does not matter, in no way and in no direction

Just to make this a bit more accurate for any other readers, that's only true for the domain name (and subdomain). If you go to example.com/index.html, it could also have an Index.html that's an entirely different file. Capitalization matters elsewhere.

https://example.com/foo.php is not the same as https://example.com/FOO.PHP.

Directories are also case-dependent.

https://example.com/foo/bar.html is not the same as https://example.com/FOO/bar.html.

But, yes... https://example.com is the same as https://example.com.

 

[MikeRocor]

I'm using firefox 133.0.3 with some ad blocking and privacy extensions on Tiny Core 17.0, 64 bit, and the site displays (apparently) correctly for me.

My user agent string is

Mozilla/5.0 (X11; Linux x86_64; rv:151.0) Gecko/20100101 Firefox/151.0

 

[GatorsFan]

The capitalization does not matter, in no way and in no direction. What would matter is if the html they serve references a wrong image file name to show. In this case, you would not see an image by spoofing the user-agent.

The reason probably is, that they (the garden shop) or their provider have some network firewall to block bots and that is misconfigured. It happens. Linux is not so widely used, so it can slip through testing easier, I guess.

There are some instances where companies deliberately discriminate users by filtering browser agents, more regularly it is geoblocking. A known example is Apple, they blocked requests by "apple foreign" user-agents to their maps service for a while. Other examples that still block are in the first post of https://github.com/whatwg/html/issues/10518

Linux is case-sensitive when it comes to file and directory names. as @KGIII has stated This means that FileName.txt and filename.txt are seen as completely different files, and Images and images are seen as completely different directories. Windows is not case-sensitive, but capitalization matters when working with Linux-based systems.

Linux Case Sensitivity - HelioHost Wiki

wiki.helionet.org

My default user-agent is
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36
I live in Florida and growhoss.com does not display images every other site works as advertised
- It does not work if I just change the browser, I have to change the OS as well and it cannot be Linux it still does not work

This is what the site looks like with no add-ons running and default user agent - as you can see - no images

This is what it looks like once I enabled UA Switcher Pro to Chrome 124 Windows 11
everything works as designed

So as Shakespeare would say there is "Something is rotten in the state of Denmark" - go figure

 

[theLegionWithin]

yeah that's weird. I have the same issue on that site using Chrome, Chromium, or Firefox.

 

[Condobloke]

I am using Librewolf:

To get pics displayed I changed the language from United States to Canada

 

[wizardfromoz]

To get pics displayed I changed the language from United States to Canada

Nice tip, Brian, I had the same lack of images on a Standard Firefox (151.01) and once I changed from US to Canada, it worked fine.

Wizard

 

[wizardfromoz]

Rinse and repeat - same applies to Waterfox.

US - no go

Change to Canada - works

 

[GatorsFan]

I am using Librewolf:
View attachment 32441

To get pics displayed I changed the language from United States to Canada

If you look your image it goes to https://www.thiessentillage.com/hoss a different website - they just sell Hoss equipment in Canada - the parent website is https://www.thiessentillage.com/ then click on Brands at the top of page then click on Hoss - so not the same as https://growhoss.com/

 

[Trml]

https://example.com/foo/bar.html is not the same as https://example.com/FOO/bar.html.

But, yes... https://example.com is the same as https://example.com.

Well, @GatorsFan only quoted the domain (growhoss.com) and that's perfectly reasonable. The webserver decides the default file to serve, it can be html, php or something else. If that initial file or any subsequent references files (images here) to load with wrong capitalization, it is their setup, not dependent on the client web browser/OS.

Going even a bit further, there is no RFC/web standard that prescribes a website must have an Index/index/....html or anything else. Web standards stipulate how to connect to a host (http GET method) and that's it.

So as Shakespeare would say there is "Something is rotten in the state of Denmark" - go figure

I repeat the url from my first post https://github.com/whatwg/html/issues/10518
Try the URL https://digits.t-mobile.com/ from the first post in the issue report. I bet it won't work, it does not for me (in the EU on Linux). That's the cause.

 

[wizardfromoz]

- so not the same

Gotcha.

So revisited via your link.

No problems for me, shows all.

Wiz

 

[GatorsFan]

Well, @GatorsFan only quoted the domain (growhoss.com) and that's perfectly reasonable. The webserver decides the default file to serve, it can be html, php or something else. If that initial file or any subsequent references files (images here) to load with wrong capitalization, it is their setup, not dependent on the client web browser/OS.

Going even a bit further, there is no RFC/web standard that prescribes a website must have an Index/index/....html or anything else. Web standards stipulate how to connect to a host (http GET method) and that's it.



I repeat the url from my first post https://github.com/whatwg/html/issues/10518
Try the URL https://digits.t-mobile.com/ from the first post in the issue report. I bet it won't work, it does not for me (in the EU on Linux). That's the cause.

I can get to both of those web sites with no issues

 

[GatorsFan]

Gotcha.

So revisited via your link.

No problems for me, shows all.

Wiz

I edited my post #10 to read - "so not the same as https://growhoss.com/"
they are two completely different websites

 

[Thunderpants]

Firefox 152.0.3 also failed to show images on the linked site. The 'User-Agent Switcher and Manager' extension to Firefox also fixed it as described. It comes with Mozilla's recommended security badge so a useful extension to the Firefox arsenal.

 

[ron.alan]

I see the images no problem. And this is on Pale Moon. But no images on Chromium. Wow, this is a first . . . a problem website on Chromium but works perfectly on Pale Moon.

BTW, thanks for this. This could be a website I order off of.

 

[GatorsFan]

I see the images no problem. And this is on Pale Moon. But no images on Chromium. Wow, this is a first . . . a problem website on Chromium but works perfectly on Pale Moon.

BTW, thanks for this. This could be a website I order off of.

Yep tried Pale Moon 34.3.1 site worked just fine - so that begs the question as to what is different between Pale Moon and a new version of Firefox

 

[ron.alan]

so that begs the question as to what is different between Pale Moon and a new version of Firefox

According to someone on the Pale Moon forum, the pics are in jpegxl format, which Chromium does not yet support. What version of Firefox are you on? FF has experimental support for jpegxl starting with version 152.

 

[KGIII]

so that begs the question as to what is different between Pale Moon and a new version of Firefox

It's possible to use different code based on the user's browser. They could have misconfigured this.

It's quite likely something on their end, and not something on our end.