[MAGNOLIA-2387] Request stored in WebContext is not updated after a forward/includes Created: 20/Sep/08  Updated: 23/Jan/13  Resolved: 05/Dec/08

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.6.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Fabrizio Giustina Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MAGNOLIA-3338 Context is not updated on include req... Closed
dependency
is depended upon by MAGNOLIA-1455 Remove usage of HttpServletRequest an... Closed
is depended upon by MAGNOLIA-2494 Add support for re-execution of filte... Closed
relation
is related to MAGNOLIA-2472 GZip Filter throws IllegalStateExcept... Closed
Template:
Patch included:
Yes
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   

The request stored in WebContext by the ContextFilter is never updated, and may miss parameters added by a forward.

For example, using a virtualUri filter in order to forward from /test/param.html to test..html?x=param I get different results when I do:
request.getParam("x") --> "param"
((WebContext) MgnlContext.getInstance()).getRequest().getParam("x") --> null

this also means that paragraphs never see parameters added by a forward, since the paragraph renderer gets the request from the context. Looks like a regression from 3.5, since I was using this kind of forwards and they stopped working after upgrading to 3.6 (not sure about which change in the filters has caused this).

I would propose to fix it by updating the request stored in WebContext any time ContextFilter processes the request. A good fix, without modifying in any way the WebContext interface, is doing something like the following:

        if (!MgnlContext.hasInstance() || MgnlContext.isSystemInstance())
        {
            MgnlContext.initAsWebContext(request, response, servletContext);
            contextSet = true;
        }
+        else
+        {
+            // update request
+            WebContext webContext = (WebContext) MgnlContext.getInstance();
+            webContext.init(request, response, servletContext);
+        }
+

I would like to commit this to 3.6.2, this can be a very annoying bug for anyone using forwards with parameters. Any objection?



 Comments   
Comment by Magnolia International [ 24/Sep/08 ]

Hmm, yeah, this was a fishy area; there is or was a reason for all this, related to resetting the filter chain, dispatchers and forwards.
We have to release 3.6.2 next week, and I'm afraid we'll have no time to test this. Can this wait 3.6.3 for you?

Comment by Magnolia International [ 25/Sep/08 ]

Fabrizio,

Two more things:

  • I'm not at all against the patch, but am i just a little wary of past issues we've had with forwards and includes etc, especially with Weblogic or Websphere behaving their own way (see the encoding issue we're having again with WL...)
  • I'm surprised you're saying virtualUri with forwards and parameters don't work anymore, since we have one of the default ones doing just that ("messages" in the adminCentral module)
Comment by Philipp Bracher [ 30/Sep/08 ]

The messages.js forward works because it is forwarded to a admin central page which uses the original request to set the parameters (no call to ctx). The described problem affects only code to which the request is not passed and the context must be used.

Comment by Philipp Bracher [ 30/Sep/08 ]

Ideally we would reset the request to the former value once the context filter returns (by using a stack?)

Comment by Philipp Bracher [ 02/Oct/08 ]

The issue is even more complex: we don't update the context on includes. To solve that we would have to execute the filter chain on includes too but only execute the context filter then. I am not sure but some of the issues might be related to that fact:

Comment by Philipp Bracher [ 04/Oct/08 ]

And when ever a response is wrapped the context must be updated too (cache, ...)

Comment by Jan Haderka [ 05/Dec/08 ]

Request and Response is now correctly updated in context and all other places during forwards. Include part will be dealt with in separate issue (MAGNOLIA-2387) later.

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