Page cache matching is case insensitive, which may lead to the return of cached 404's on existing pages.
To reproduce:
1. Enable 'normal' page caching.
2. Visit the URL http://example.com/NODE - a 404 page not found is returned
3. Visit the URL http://example.com/node - the same 404 page not found is returned.
On MySQL (5.0.21, 4.0.24), PHP ( 5.1.4, 4.3.10-18), Apache (2.2.2)
Now, changing cid to be a VARCHAR BINARY allows case-sensitive matching, but I haven't given all the possible implications much thought yet.
Why critical? Because a user may have a hard time getting a site back to serving normal pages without access to the database.
Comment | File | Size | Author |
---|---|---|---|
#6 | cache_page_case_sensitive.patch_0.txt | 1.39 KB | Heine |
#3 | cache_page_case_sensitive.patch.txt | 737 bytes | Heine |
Comments
Comment #1
chx CreditAttribution: chx commentedMaking cid case snesitive at this point -1
What about adding a simple PHJP string compare instead.
Comment #2
pwolanin CreditAttribution: pwolanin commentedIn general, it seems that URLs should be considered case sensitive. So, it seems like there either needs to be a case-insensitive path/menu lookup to start with, or case-sensitive caching as proposed.
Comment #3
Heine CreditAttribution: Heine commentedWe'd only modify the cid colum in the table cache_page and not touch the rest of the cache. I'm not sure how we could do a simple string comparison without extensive surgery to cache_get / cache_set.
Postgresql shouldn't have this issue as it always matches in a case-sensitive manner.
Comment #4
pwolanin CreditAttribution: pwolanin commentedOk, I had been ignorant on this topic, but after some research this seems like the right approach since mysql.com says
.
see: http://dev.mysql.com/doc/refman/5.1/en/case-sensitivity.html and http://dev.mysql.com/doc/refman/5.1/en/binary-varbinary.html
Comment #5
chx CreditAttribution: chx commentedI think you need patch some upgrade too.
Comment #6
Heine CreditAttribution: Heine commentedIndeed.
Comment #7
drummCommitted to HEAD.
Comment #8
(not verified) CreditAttribution: commentedComment #9
CarbonPig CreditAttribution: CarbonPig commentedModifying the mySQL table from within phpMyAdmin solves the issue of making your URL aliases case sensitive.
You simply change the database filed in URL ALIAS from:
dst varchar
To:
dst varbinary(128)
Hope that makes sense.
TAGS: How to make your url aliases case sensitive, make alias case sensitive, enable, disable
Comment #10
dczaretsky CreditAttribution: dczaretsky commentedHi,
I'm having this same problem in Drupal 7. When pages are cached, it is not case-sensitive. Therefore, when an erroneous page is called, the 404 error is cached, and then subsequent calls to the correct page return a 404 error.
I looked into the system.install module, and the above patch will not work. It seems they made it a bit more difficult to enable binary matching. A single schema is applied to all cache types as follows, and so you cannot make the cid binary without affect all other cache tables:
$schema['cache_page'] = $schema['cache'];
In most cases, URLs are case sensitive, so this should be fixed in the system module.
Comment #11
MixologicI think you might be having some other problem.
As far as I can tell, URL aliases in drupal *are not* case sensitive. so a call to http://mywebsite.com/content/MyPage will return http://mywebsite.com/content/mypage . And subsequent hits to any variant of casing will return the cached page.
So I dont know how you would ever get the 404 cached in the first place. What kind of page callback is it? A node or view? Or is it a custom menu callback you've added yourself?
Comment #12
Elijah LynnCurrent Drupal 7 behavior is that the page caching is not case-sensitive. I just tested the below two scenarios with Drupal page cache.
e.g. /node/1 & /nODE/1 are the same cache object
e.g. /foo & /FOO are the same cache object
This is interested because Acquia's default VCL is treating them as separate objects (for our org at least). This means more load on origin if people type the case differently and more importantly, purging the content from varnish is not accurate.
And cache invalidation is a reason why Drupal should not be case-sensitive, not to mention a better end user experience. Why have users be on the waiting end of creating multiple cache objects for the same piece of content?
Comment #13
Elijah LynnWorth noting that in default Drupal 8 install this is opposite behavior and aliases are case-sensitive.
http://sandbox/d8/foo == 200, http://sandbox/d8/fOO == 200
But x-Drupal-Cache: miss on the second one first time around
Of note is also this...
http://sandbox/d8/node/1 == 200, http://sandbox/d8/nOde/1 == 404
I guess maybe the external cache invalidation strategy will have to change with this behavior or we will need to make Drupal 8 case-insensitive again.