Thank you for your answer; I have created the JIRA issue
https://issues.apache.org/jira/browse/WICKET-2615
Since the problem only occurs with the default render strategy
RenderStrategy.REDIRECT_TO_BUFFER in combination with certain URL coding
strategies, there are workarounds, such as using
RenderStrategy.REDIRECT_TO_RENDER, therefore I suppose it should be
categorized as Minor.
However, I think this issue points at potential problems with the key
used with RenderStrategy.REDIRECT_TO_BUFFER for storing buffered
responses that might (in combination with certain URL coding strategies)
go beyond the issue observed with URL rewriting in this case - so,
although it is not urgent, it might still be important.
Adrian Engler
-Original Message-
From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com]
Sent: Montag, 14. Dezember 2009 15:00
To: users@wicket.apache.org
Subject: Re: Buffer not retrieved if RENDER_TO_BUFFER is used with
IndexedHybridUrlCodingStrategy and the web server uses URL rewriting
(cookies switched off)
Ah... ok. this is a bug, file a JIRA issue please.
Martijn
On Mon, Dec 14, 2009 at 2:59 PM, Martijn Dashorst
wrote:
> Use the URL Rewriting features of your container.
>
> Martijn
>
> On Mon, Dec 14, 2009 at 2:52 PM, Engler Adrian
wrote:
>> Hello,
>>
>> In a Wicket web application (Wicket 1.4.3) I noticed that feedback
>> messages were not displayed when cookies were disabled in the
browser.
>> It turned out that this problem had to do with the combination of the
>> URL coding strategy that was used (IndexedHybridUrlCodingStrategy)
and
>> the render strategy, RenderStrategy.REDIRECT_TO_BUFFER (which is the
>> default). What actually happens when cookies are switched off is that
>> the page is rendered to a buffer, a redirect is sent, but then the
>> server does not recognize that it should use the contents of the
buffer
>> because the URLs do not match, and therefore the page is rendered
again
>> (this time without the feedback messages because they are now already
>> marked as rendered), the buffer is not used.
>>
>> If the render strategy is changed to
RenderStrategy.REDIRECT_TO_RENDER,
>> there is no problem without cookies; the problem only exists when the
>> page is first rendered to a buffer and then this buffer is not used.
>>
>> The attached minimal application demonstrates this behavior: When
>> cookies are enabled, you can click the button "Show feedback message"
on
>> the page, and a message "Info message generated " is shown. If
>> cookies are disabled, no feedback message is shown.
>>
>> Example from debugging:
>> In WebRequestCycle.redirectTo(...), the variable redirectURL is
assigned
>> the value home.0;jsessionid=1ie4koskoj2bn; addBufferedResponse is
then
>> called with the value home.0;jsessionid=1ie4koskoj2bn for buffered.
>> Then, after the redirect, in WicketFilter.doGet(...),
>> WebApplication.popBufferedResponse is called with the value home.0
for
>> the relativePath parameter. In that method, the buffered response is
not
>> found (because the real key is home.0;jsessionid=1ie4koskoj2bn).
>>
>> The problem is that when the buffer is put to the map, a key that
>> includes the session ID is used, while for retrieval of the buffered
>> page, a key without the session ID is used.
>>
>> This problem occurs when IndexedHybridUrlCodingStrategy or the super
>> class HybridUrlCodingStrategy is used.
>>
>> If the page is not mounted (and not bookmarkable after the form has
been
>> submitted), there are no problems without cookies because a key
without
>> the jsessionid is used for storing the buffered response in a map.
This
>> has to do with the fact that in WebRequestCycle.redirectTo(...) only
the
>> part of the URL after the "?" is used as a key:
>>
>> int index = stripped.indexOf("?");
>> [...]
>> ((WebApplication) application).addBufferedResponse(sessionId,
>> stripped.substring(index + 1), servletResponse);
>>
>> If the page is mounted with a HybridUrlCodingStrategy, the value
>> assigned to the variable stripped is a string without a "?",
therefore,
>> index has the value -1 and a URL with jsessionid is used as a key for
>> the buffered page.
>>
>> I think it might be good if someone has a look into this; it might
also
>> be hat in some settings a response is rendered twice (first into the
>> buffer then for the client because the buffer is not retrieved
because
>> of a URL mismatch) without users noticing anything (as long as
feedback
>> messages are not used).
>>
>> Thank you!
>>
>>
>>
>> -