New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images named *.JPG aren't displayed in the frontend #4364

Closed
cmyk opened this Issue May 22, 2012 · 27 comments

Comments

Projects
None yet
6 participants
@cmyk

cmyk commented May 22, 2012

Images named *.JPG (not *.jpg) aren't displayed in the frontend, namely when clicked upon and opened in a new window/lightbox.
Users often upload images directly from the camera where they are named *.JPG.

@danielritter

This comment has been minimized.

Show comment
Hide comment
@danielritter

danielritter May 23, 2012

Kann ich bestätigen.

danielritter commented May 23, 2012

Kann ich bestätigen.

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer May 25, 2012

Member

Welche Contao-Version betrifft das?

Member

leofeyer commented May 25, 2012

Welche Contao-Version betrifft das?

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk May 25, 2012

Hab's gerade noch im 2.11.3 reproduziert.

cmyk commented May 25, 2012

Hab's gerade noch im 2.11.3 reproduziert.

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer May 31, 2012

Member

I cannot reproduce the issue, though. I renamed music_academy/james-wilson.jpg to … wilson.JPG and updated the news article accordingly. I then opened the image in the mediabox and it was displayed correctly.

How exactly did you reproduce the issue?

Member

leofeyer commented May 31, 2012

I cannot reproduce the issue, though. I renamed music_academy/james-wilson.jpg to … wilson.JPG and updated the news article accordingly. I then opened the image in the mediabox and it was displayed correctly.

How exactly did you reproduce the issue?

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Jun 4, 2012

Maybe it has to do with case sensitive file systems? The problem occured live (redhat) and locally (OS X 10.6).
Steps to repro: upload image named *.JPG and check if it's displayed in the mediabox.

cmyk commented Jun 4, 2012

Maybe it has to do with case sensitive file systems? The problem occured live (redhat) and locally (OS X 10.6).
Steps to repro: upload image named *.JPG and check if it's displayed in the mediabox.

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 10, 2012

Member

What does your .htaccess file look like?

Member

leofeyer commented Jun 10, 2012

What does your .htaccess file look like?

@xchs

This comment has been minimized.

Show comment
Hide comment
@xchs

xchs Jun 11, 2012

Contributor

Da stimmt aber einiges nicht:

  • Zeile RewriteEngine Off: Hier wird die Rewrite Engine komplett abgeschalten, u.zw. für alle Requests
  • Zeile RewriteRule .*\.html$ index.php [L] macht wohl auch keinen Sinn mehr, wenn Du keinen URL Suffix verwenden möchtest (siehe die entsprechenden Direktiven vorher)

Nachtrag: Möglicherweise wurden aber auch nur einige Tags (<...>) hier von GitHub ausgefiltert.

Contributor

xchs commented Jun 11, 2012

Da stimmt aber einiges nicht:

  • Zeile RewriteEngine Off: Hier wird die Rewrite Engine komplett abgeschalten, u.zw. für alle Requests
  • Zeile RewriteRule .*\.html$ index.php [L] macht wohl auch keinen Sinn mehr, wenn Du keinen URL Suffix verwenden möchtest (siehe die entsprechenden Direktiven vorher)

Nachtrag: Möglicherweise wurden aber auch nur einige Tags (<...>) hier von GitHub ausgefiltert.

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Jun 11, 2012

Nein, stimmt schon: http://pastebin.com/ybhpJSaW
GFM ist schuld.

cmyk commented Jun 11, 2012

Nein, stimmt schon: http://pastebin.com/ybhpJSaW
GFM ist schuld.

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Jun 19, 2012

Here's my .htaccess: http://pastebin.com/1Px0jCsA
Note Line 228. Without that line the folderurl wouldn't work.
Anyways, even if I disable rewriting URLs and the folderurl extension, the problem with JPG vs jpg persists.
This is the exact same file:
http://www.alpsteinsport.ch/tl_files/alpsteinsport/Fotoalben/Fussball_Freizeitschuhe/DSC01463.JPG
http://www.alpsteinsport.ch/tl_files/alpsteinsport/Fotoalben/Fussball_Freizeitschuhe/DSC01463-1.jpg
If I disable my .htaccess completely, both images are displayed.

cmyk commented Jun 19, 2012

Here's my .htaccess: http://pastebin.com/1Px0jCsA
Note Line 228. Without that line the folderurl wouldn't work.
Anyways, even if I disable rewriting URLs and the folderurl extension, the problem with JPG vs jpg persists.
This is the exact same file:
http://www.alpsteinsport.ch/tl_files/alpsteinsport/Fotoalben/Fussball_Freizeitschuhe/DSC01463.JPG
http://www.alpsteinsport.ch/tl_files/alpsteinsport/Fotoalben/Fussball_Freizeitschuhe/DSC01463-1.jpg
If I disable my .htaccess completely, both images are displayed.

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Jun 19, 2012

Ha! Just found the problem:
Lines 209–211:
<FilesMatch "\.(htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|eot|woff|svg|ttf|pdf|gz)$"> RewriteEngine Off </FilesMatch>

Add JPG to that list and it works. Maybe make that whole thing case-insensitive?

cmyk commented Jun 19, 2012

Ha! Just found the problem:
Lines 209–211:
<FilesMatch "\.(htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|eot|woff|svg|ttf|pdf|gz)$"> RewriteEngine Off </FilesMatch>

Add JPG to that list and it works. Maybe make that whole thing case-insensitive?

@xchs

This comment has been minimized.

Show comment
Hide comment
@xchs

xchs Jun 19, 2012

Contributor

Huh, do we really need to write something like this here?

<FilesMatch "\.([Hh][Tt][Mm][Ll]|[Pp][Hh][Pp]|[Jj][Ss]|[Cc][Ss][Ss]|[Hh][Tt][Cc]|[Pp][Nn][Gg]|[Gg][Ii][Ff]|[Jj][Pp][Ee]?[Gg]|[Ii][Cc][Oo]|[Xx][Mm][Ll]|[Cc][Ss][Vv]|[Tt][Xx][Tt]|[Ss][Ww][Ff]|[Ff][Ll][Vv]|[Ee][Oo][Tt]|[Ww][Oo][Ff][Ff]|[Ss][Vv][Gg]|[Tt][Tt][Ff]|[Pp][Dd][Ff]|[Gg][Zz])$">
...

Quite weird!

Contributor

xchs commented Jun 19, 2012

Huh, do we really need to write something like this here?

<FilesMatch "\.([Hh][Tt][Mm][Ll]|[Pp][Hh][Pp]|[Jj][Ss]|[Cc][Ss][Ss]|[Hh][Tt][Cc]|[Pp][Nn][Gg]|[Gg][Ii][Ff]|[Jj][Pp][Ee]?[Gg]|[Ii][Cc][Oo]|[Xx][Mm][Ll]|[Cc][Ss][Vv]|[Tt][Xx][Tt]|[Ss][Ww][Ff]|[Ff][Ll][Vv]|[Ee][Oo][Tt]|[Ww][Oo][Ff][Ff]|[Ss][Vv][Gg]|[Tt][Tt][Ff]|[Pp][Dd][Ff]|[Gg][Zz])$">
...

Quite weird!

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 20, 2012

Member

Hm, please try the following:

<FilesMatch "\.(?i:htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|eot|woff|svg|ttf|pdf|gz)$">
RewriteEngine Off
</FilesMatch>

(The difference is the ?i: at the beginning of the regular expression.)

Member

leofeyer commented Jun 20, 2012

Hm, please try the following:

<FilesMatch "\.(?i:htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|eot|woff|svg|ttf|pdf|gz)$">
RewriteEngine Off
</FilesMatch>

(The difference is the ?i: at the beginning of the regular expression.)

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 20, 2012

Member

BTW, which Apache version are you on?

Member

leofeyer commented Jun 20, 2012

BTW, which Apache version are you on?

@xchs

This comment has been minimized.

Show comment
Hide comment
@xchs

xchs Jun 20, 2012

Contributor

BTW, which Apache version are you on?

In fact, this is the point with the "?i" parameter...

Contributor

xchs commented Jun 20, 2012

BTW, which Apache version are you on?

In fact, this is the point with the "?i" parameter...

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Jun 21, 2012

Yep, make the whole regex case-insensitive is the solution.
Thanks, Leo!
Apache 2.2.22

cmyk commented Jun 21, 2012

Yep, make the whole regex case-insensitive is the solution.
Thanks, Leo!
Apache 2.2.22

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 21, 2012

Member

Strange that the HTML5Boilerplate does not use case-insensitive expressions. Is this maybe configurable in the Apache settings?

Member

leofeyer commented Jun 21, 2012

Strange that the HTML5Boilerplate does not use case-insensitive expressions. Is this maybe configurable in the Apache settings?

@xchs

This comment has been minimized.

Show comment
Hide comment
@xchs

xchs Jun 21, 2012

Contributor

Does this mean that we have to add the mode modifier ?i: to all the FilesMatch directives in the .htaccess file? Is there some performance impact when we apply this modifier too often in the server configuration file?

Contributor

xchs commented Jun 21, 2012

Does this mean that we have to add the mode modifier ?i: to all the FilesMatch directives in the .htaccess file? Is there some performance impact when we apply this modifier too often in the server configuration file?

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 22, 2012

Member

No, this cannot be the solution. It did work on my system without the modifier, so it is definitely not required. Maybe a configurable Apache feature?

Member

leofeyer commented Jun 22, 2012

No, this cannot be the solution. It did work on my system without the modifier, so it is definitely not required. Maybe a configurable Apache feature?

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 22, 2012

Member

I am getting closer to the core of the problem. It has to do with the file system it seems:

https://trac.macports.org/ticket/7277
http://support.apple.com/kb/TA22750?viewlocale=en_US

So, which file system are you using?

Member

leofeyer commented Jun 22, 2012

I am getting closer to the core of the problem. It has to do with the file system it seems:

https://trac.macports.org/ticket/7277
http://support.apple.com/kb/TA22750?viewlocale=en_US

So, which file system are you using?

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Jun 22, 2012

It's a problem, both on HFS+ and on Linux ext4.

cmyk commented Jun 22, 2012

It's a problem, both on HFS+ and on Linux ext4.

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 22, 2012

Member

Then it is what @xchs asked above: Is there some performance impact when we apply this modifier too often in the server configuration file?

Member

leofeyer commented Jun 22, 2012

Then it is what @xchs asked above: Is there some performance impact when we apply this modifier too often in the server configuration file?

@xchs

This comment has been minimized.

Show comment
Hide comment
@xchs

xchs Jun 22, 2012

Contributor

Searched awhile and found some interesting remarks in the book "Mastering Regular Expressions" by Jeffrey Friedl regarding optimizing regular expressions for efficient performance in general, and case-insensitive pattern modifiers in particular.

Since Apache 2 bundles a PCRE library I guess that many of the statements apply here as well:

The Efficiency Penalty of the /i Modifier

If you ask Perl do match in a case-insensitive manner, common sense tells you that you are asking for more work to be done. You might be surprised, though, to find out just how much extra work that really is.
Before a match or substitution operator applies an /i-governed regex, Perl first makes a temporary copy of the entire target string. This copy is in addition to any copy in support of $& and friends. The latter is done only after a successful match, while the one to support a case-insensitive match is done before the attempt. After the copy is made, the engine then makes a second pass over the entire string, converting any uppercase characters to lowercase. The result might happen to be :he same as the original, but in any case, all letters are lowercase. This goes hand in hand with a bit of extra work done during the compilation of the regex to an internal form. At that
time, uppercase letters in the regex are converted to lowercase as well. The result of these two steps is a string and a regex that then matches normally—nothing special or extra needs to be done within the actual matching portion of the regex engine. It all appears to be a very tidy arrangement, but this has got to be one of the most gratuitous inefficiencies in all of Perl.

Methods to implement case-insensitive matching

There are (at least) two schools of thought on how to implement case-insensitive matching. We've just seen one, which I call string oriented (in addition to "gratuitously inefficient"). The other, which I consider to be far superior, is what I would call regex oriented. It works with the original mixed-case target string, having the engine itself make allowances for case-insensitive matching as the need arises.

A few /i benchmarks

[...] Simply adding the /i modifier [...] slowed the program by four orders of magnitude [...]

Final words about the /i penalty

Foremost: don't use /i unless you really have to. Blindly adding it to a regex that doesn't require it invites many wasted CPU cycles. In particular, when working with long strings, it can be a huge benefit to rewrite a regex to mimic the regex-oriented approach to case insensitivity, as I did with the last two benchmarks.

However, If someone can do some further "ab" testing concerning this issue it would be great, too.

Contributor

xchs commented Jun 22, 2012

Searched awhile and found some interesting remarks in the book "Mastering Regular Expressions" by Jeffrey Friedl regarding optimizing regular expressions for efficient performance in general, and case-insensitive pattern modifiers in particular.

Since Apache 2 bundles a PCRE library I guess that many of the statements apply here as well:

The Efficiency Penalty of the /i Modifier

If you ask Perl do match in a case-insensitive manner, common sense tells you that you are asking for more work to be done. You might be surprised, though, to find out just how much extra work that really is.
Before a match or substitution operator applies an /i-governed regex, Perl first makes a temporary copy of the entire target string. This copy is in addition to any copy in support of $& and friends. The latter is done only after a successful match, while the one to support a case-insensitive match is done before the attempt. After the copy is made, the engine then makes a second pass over the entire string, converting any uppercase characters to lowercase. The result might happen to be :he same as the original, but in any case, all letters are lowercase. This goes hand in hand with a bit of extra work done during the compilation of the regex to an internal form. At that
time, uppercase letters in the regex are converted to lowercase as well. The result of these two steps is a string and a regex that then matches normally—nothing special or extra needs to be done within the actual matching portion of the regex engine. It all appears to be a very tidy arrangement, but this has got to be one of the most gratuitous inefficiencies in all of Perl.

Methods to implement case-insensitive matching

There are (at least) two schools of thought on how to implement case-insensitive matching. We've just seen one, which I call string oriented (in addition to "gratuitously inefficient"). The other, which I consider to be far superior, is what I would call regex oriented. It works with the original mixed-case target string, having the engine itself make allowances for case-insensitive matching as the need arises.

A few /i benchmarks

[...] Simply adding the /i modifier [...] slowed the program by four orders of magnitude [...]

Final words about the /i penalty

Foremost: don't use /i unless you really have to. Blindly adding it to a regex that doesn't require it invites many wasted CPU cycles. In particular, when working with long strings, it can be a huge benefit to rewrite a regex to mimic the regex-oriented approach to case insensitivity, as I did with the last two benchmarks.

However, If someone can do some further "ab" testing concerning this issue it would be great, too.

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 25, 2012

Member

As a first consequence, I have removed the /i modifier where applicable in 0538a85. (Although this has nothing to do with the .htaccess file.)

Member

leofeyer commented Jun 25, 2012

As a first consequence, I have removed the /i modifier where applicable in 0538a85. (Although this has nothing to do with the .htaccess file.)

@leofeyer

This comment has been minimized.

Show comment
Hide comment
@leofeyer

leofeyer Jun 26, 2012

Member

I have added a note in 5bb272a.

Member

leofeyer commented Jun 26, 2012

I have added a note in 5bb272a.

@Ruudt

This comment has been minimized.

Show comment
Hide comment
@Ruudt

Ruudt Feb 11, 2013

Just asking: aren't most servers on case sensitive filesystems? If so, shouldn't the default be insensitive? I ran into this problem today and wondered why the case insensitive wasn't the default with a note on how to make it more efficient instead.

Ruudt commented Feb 11, 2013

Just asking: aren't most servers on case sensitive filesystems? If so, shouldn't the default be insensitive? I ran into this problem today and wondered why the case insensitive wasn't the default with a note on how to make it more efficient instead.

@cmyk

This comment has been minimized.

Show comment
Hide comment
@cmyk

cmyk Apr 16, 2013

@Ruudt Absolutely! This is totally backwards.

cmyk commented Apr 16, 2013

@Ruudt Absolutely! This is totally backwards.

@benunternaehrer

This comment has been minimized.

Show comment
Hide comment
@benunternaehrer

benunternaehrer May 9, 2014

I had the same problem today... it works for me by adding JPG to the .htaccess... Is it possible to include JPG in the default .htaccess?

benunternaehrer commented May 9, 2014

I had the same problem today... it works for me by adding JPG to the .htaccess... Is it possible to include JPG in the default .htaccess?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment