[MAGNOLIA-560] Too eager caching in Path.getURI Created: 04/Oct/05  Updated: 10/Oct/07  Resolved: 23/Jan/06

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.1 Final
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andreas Brenk Assignee: Sameer Charles
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 5m
Time Spent: Not Specified
Original Estimate: 5m

Issue Links:
relation
is related to MAGNOLIA-1698 Review usage of originalURI/currentUR... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

I have wrapped Magnolia in Spring WebMVC ServletWrappingControllers. But the problem is possible in other "pure web.xml" situations, too. In order to extend a Magnolia based Website with some business logic for a custom search form I intercept a special URL /searchForm, then forward using the RequestDispatcher to a Magnolia handled /searchFormResult.html page. The assigned template displays the search results it gets from a request attribute.

This worked perfectly well in the authoring environment but stopped working in a public instance (as long as one didn't log in to the public's adminCentral to be precise). The reason being SecurityFilter's isAllowed method. If a session is authorized the method call returns before calling SecureURI.isProtected(Path.getURI(req)) which caches the decoded URI in a request attribute. Problem is: this results in caching "/searchForm" and not "/searchFormResult.html", as the filter runs before the business logic servlet and its call to the RequestDispatcher's forward() method.

As the caching doesn't even result in a measurable performance improvement (System.currentTimeInMillis() results in the same value before and after the call to getDecodedURI()...) I suggest to always return getDecodedURI(req) and drop the cache.



 Comments   
Comment by Sameer Charles [ 30/Nov/05 ]

I agree that you wont see any performance improvement for one call, but one request to template or to admin interface calls this method multiple times and will end up creating unneccesary string objects, another reason to cache this is to allow templates to have access to the original URI (in templates request.getURI will be a path of a JSP or servlet) instead of parsing java servlet path.

see: Path.resetURI(HttpServletRequest)

Comment by Sameer Charles [ 20/Jan/06 ]

will test and remove URI caching

Comment by Sameer Charles [ 23/Jan/06 ]

fixed

Comment by Magnolia International [ 10/Oct/07 ]

This seems related to MAGNOLIA-1698

Comment by Magnolia International [ 10/Oct/07 ]

see linked issue.

Generated at Mon Feb 12 03:18:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.