You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Frédéric Donckels <fr...@gmail.com> on 2011/09/21 14:04:14 UTC

Re: Peculiar Redirect Behaviour

Hi Martin,

Tried to reach you on ##wicket, but you just left :)

As part of https://issues.apache.org/jira/browse/WICKET-3885
in ServletWebResponse, in the sendRedirect(..) method,

you made the following change:
			redirect = true;
			url = getAbsoluteURL(url);  -----> removed
			url = encodeRedirectURL(url);

This makes the url encoding directly delegated to the container
servlet response.

This breaks the bookmarkable links on Webpshere with Wicket 1.5 after RC 5.1

I have a link to another page created using bookmarkable page link.
When in the WebPageRenderer, the storeBufferedResponse(..) method is
called, the url object contains wicket / bookmarkable / com.viveo....
segements. This is used to created the key for the buffered response.

When the redirect is written to the response instance, without the
getAbsoluteURL, the "wicket/bookmarkable" part is not written in the
answer. This, later, when the redirect is handled, makes it impossible
to retrieve the buffered response (the buffered mapper cannot build
the proper id later without the wicket/bookmarkable part and the end
result is 404) .

If this is a fix for an ajax issue, could it be done only in the
"isAjax()" part of that method?

Regards,

Frederic




On Wed, Aug 31, 2011 at 16:47, Martin Grigorov <mg...@apache.org> wrote:
> 2011/8/31 Frédéric Donckels <fr...@gmail.com>:
>> This happens with Wicket 1.5 RC7 on Websphere)
>> (it looks, pending further investigations, but Websphere is insanely
>> slow, that it doesn't happen within JBoss or if we use 1.5 RC 5.1)
>>
>> The page object is rendered in a buffered response but when the
>> redirect for the web response is handled the server 404's.
> what is the current url when Wicket looks in the map with stored responses ?
>>
>> When I step-by-step debug, inside WebApplication.hasBufferedResponse,
>> I see two values:
>> Vt5jB33iN64TTSvEKU4xchbwicket/bookmarkable/com.viveo.ingissa.alert.web.compliance.ComplianceListPage?2&riskType=ALERT.TRN.COFI
> when this was saved you were at /something1
>> and
>> Vt5jB33iN64TTSvEKU4xchbcom.viveo.ingissa.alert.web.compliance.ComplianceListPage?2&riskType=ALERT.TRN.COFI
> when this was generated you were at /wicket/bookmarkable/something2
>>
>> those are supposedly addressing the same buffered response but the
>> keys are different. How could that be?
>>
>> What could be done to solve that?
>>
>> Regards,
>>
>> F.D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Peculiar Redirect Behaviour

Posted by Martin Grigorov <mg...@apache.org>.
2011/9/21 Frédéric Donckels <fr...@gmail.com>:
>> It seems to be (yet another) WebSphere issue...
> It seems to be the case, indeed (no issue with JBoss, for example).
>
> Any idea how I could address this?
I have no good solution...
As final resort you can create your WebSphereServletWebResponse that
extends ServletWebResponse and makes #sendRedirect() working for WS.
Register it by overriding
org.apache.wicket.protocol.http.WebApplication.newWebResponse(WebRequest,
HttpServletResponse)
>
> Regards,
>
> Frédéric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Peculiar Redirect Behaviour

Posted by Frédéric Donckels <fr...@gmail.com>.
> It seems to be (yet another) WebSphere issue...
It seems to be the case, indeed (no issue with JBoss, for example).

Any idea how I could address this?

Regards,

Frédéric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Peculiar Redirect Behaviour

Posted by Martin Grigorov <mg...@apache.org>.
It seems to be (yet another) WebSphere issue...

encodeURL() and encodeRedirectURL() doesn't mandate by Servlet spec
absolute URLs.
javax.servlet.http.HttpServletResponse.sendRedirect(String) is the one
that cares to make the URL absolute.

Let says you are at http://www.example.com/page1
then you make setResponsePage(SomePage.class) so the new URL should be
'wicket/bookmarkable/com.example.SomePage' and this is the key for the
buffered/stored response.

No matter whether you send
http://www.example.com/wicket/bookmarkable/com.example.SomePage (for
non-Ajax #sendRedirect() should make it absolute by spec) or
wicket/bookmarkable/com.example.SomePage (for Ajax this is enough for
document.location to make the new url) at the end the Request's Url in
the second request should be the same and it will be used as a key to
check whether there is a stored response to render.

The absolute url that is removed in this fix would break many
applications which are behind a reverse proxy. Working with relative
Urls is preferred.

2011/9/21 Frédéric Donckels <fr...@gmail.com>:
> Hi Martin,
>
> Tried to reach you on ##wicket, but you just left :)
>
> As part of https://issues.apache.org/jira/browse/WICKET-3885
> in ServletWebResponse, in the sendRedirect(..) method,
>
> you made the following change:
>                        redirect = true;
>                        url = getAbsoluteURL(url);  -----> removed
>                        url = encodeRedirectURL(url);
>
> This makes the url encoding directly delegated to the container
> servlet response.
>
> This breaks the bookmarkable links on Webpshere with Wicket 1.5 after RC 5.1
>
> I have a link to another page created using bookmarkable page link.
> When in the WebPageRenderer, the storeBufferedResponse(..) method is
> called, the url object contains wicket / bookmarkable / com.viveo....
> segements. This is used to created the key for the buffered response.
>
> When the redirect is written to the response instance, without the
> getAbsoluteURL, the "wicket/bookmarkable" part is not written in the
> answer. This, later, when the redirect is handled, makes it impossible
> to retrieve the buffered response (the buffered mapper cannot build
> the proper id later without the wicket/bookmarkable part and the end
> result is 404) .
>
> If this is a fix for an ajax issue, could it be done only in the
> "isAjax()" part of that method?
>
> Regards,
>
> Frederic
>
>
>
>
> On Wed, Aug 31, 2011 at 16:47, Martin Grigorov <mg...@apache.org> wrote:
>> 2011/8/31 Frédéric Donckels <fr...@gmail.com>:
>>> This happens with Wicket 1.5 RC7 on Websphere)
>>> (it looks, pending further investigations, but Websphere is insanely
>>> slow, that it doesn't happen within JBoss or if we use 1.5 RC 5.1)
>>>
>>> The page object is rendered in a buffered response but when the
>>> redirect for the web response is handled the server 404's.
>> what is the current url when Wicket looks in the map with stored responses ?
>>>
>>> When I step-by-step debug, inside WebApplication.hasBufferedResponse,
>>> I see two values:
>>> Vt5jB33iN64TTSvEKU4xchbwicket/bookmarkable/com.viveo.ingissa.alert.web.compliance.ComplianceListPage?2&riskType=ALERT.TRN.COFI
>> when this was saved you were at /something1
>>> and
>>> Vt5jB33iN64TTSvEKU4xchbcom.viveo.ingissa.alert.web.compliance.ComplianceListPage?2&riskType=ALERT.TRN.COFI
>> when this was generated you were at /wicket/bookmarkable/something2
>>>
>>> those are supposedly addressing the same buffered response but the
>>> keys are different. How could that be?
>>>
>>> What could be done to solve that?
>>>
>>> Regards,
>>>
>>> F.D.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org