[Bug 63282] New: Cache keys incorrect on rewrite

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 63282] New: Cache keys incorrect on rewrite

Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=63282

            Bug ID: 63282
           Summary: Cache keys incorrect on rewrite
           Product: Apache httpd-2
           Version: 2.4.38
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_cache_disk / mod_disk_cache
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

Hello all,

I've been working at this for a bit, but unfortunately been unable to find a
proper solution either in docs, trial-and-error, or the mailing list. Honestly,
I believe this might be a bug anyway, so I thought I would reach out here and
see what you all think. I've also looked in past reports and wasn't able to
find previous mentions of this, so I apologize if I missed something and this
has been reported before.

The main issue is that the Apache disk cache (specifically; I haven't tried
other caching backends on this) will cache requests with the rewritten URL when
said request was rewritten by mod_rewrite, rather than the originally-requested
resource. This is mainly evident on CMS's that use so-called "pretty URL's" or
"permalinks", where all requests are rewritten to "index.php" for processing.
So, if I request, say:

http://domain.com/page/1

This gets rewritten internally to http://domain.com/index.php and served
normally. This results in the cache key showing not the original URI, but the
rewritten one. Such as (when viewed with htcacheclean):

http://domain.com/index.php? 942 20436 200 0....etc....

This means that, should I attempt to request, say, http://domain.com/page/2,
this also gets rewritten to index.php, which causes the cache to erroneously
think it has my request in the cache and serves that instead of properly
realizing that the request is different.

I would think that expected behaviour of the cache would be to store the
request under the key as the originally-requested resource rather than whatever
it may  get rewritten to internally (redirects and such notwithstanding).
Making the above instead appear as:

http://domain.com/page/1? 942 20436 200 0....etc....

I hope this makes sense?

Thank you in advance for your help!

- Adam

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Bug 63282] Cache keys incorrect on rewrite

Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=63282

Raphaël Droz <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Raphaël Droz <[hidden email]> ---
We can think it like the opposite of
https://bz.apache.org/bugzilla/show_bug.cgi?id=21935

While #21935 is about using the rewritten query (in order to use one
deduplicated cache entry for multiple query-string), this is about not merging
distinct client URI rewritten as an identical final path.

Someone provided a neat workaround
http://mrclay.org/2013/09/13/apache-mod_cache-and-mod_rewrite-danger/ but it's
not always suitable nor desirable.

Having a better control about what the final cache entry looks wrt both URI and
query-string would be definitely nice to have!

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]