[
https://issues.apache.org/jira/browse/WICKET-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124416#comment-13124416
]
Peter Pastrnak edited comment on WICKET-4019 at 10/10/11 7:37 PM:
------------------------------------------------------------------
I checked https://issues.apache.org/jira/browse/WICKET-4113 and one reason, why
it is cached might be, that if someone calls 'setResponsePage' when processing
an Ajax request, portlet bridge does not return the original ajax redirect,
instead it forwards the redirect to the wicket filter and renders the page to
the response. But as these responses are always text based, I don't see any
reason for binary responses to be cached (but I might be wrong :)).
Anyway, as I see this as a quite big issue, I've modified the ResponseState and
created new version 5.2.1.2, that flushes the response (text and binary) every
256kB (can be changed per request using
Response.getContainerResponse().setBufferSize()).
was (Author: pasto):
I checked https://issues.apache.org/jira/browse/WICKET-4113 and one reason,
why it is cached might be, that if someone calls 'setResponsePage' when
processing an Ajax request, portlet bridge does not return the original ajax
redirect, instead it forwards the redirect to the wicket filter and renders the
page to the response. But as these responses are always text based, I don't see
any reason for binary responses to be cached (but I might be wrong :)).
Anyway, a I see this as a quite big issue, I've modified the ResponseState and
created new version 5.2.1.2, that flushes the response (text and binary) every
256kB (can be changed per request using
Response.getContainerResponse().setBufferSize()).
> Portlet Support 1.5
> -------------------
>
> Key: WICKET-4019
> URL: https://issues.apache.org/jira/browse/WICKET-4019
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-RC7
> Reporter: Peter Pastrnak
> Attachments: ResponseState.java, Wicket - Portlet.htm,
> wicket-portlet-1.5.0.zip, wicket-portlet-1.5.1.1.zip,
> wicket-portlet-1.5.1.2.zip, wicket-portlet-1.5.1.zip,
> wicket-portlet-1.5.RC7.zip, with bind(this).jpg, without bind(this).jpg
>
>
> Url returned by the RequestMapper does not seem to be properly rendered, as
> it does not encode question mark character in the Url parameter value (I
> haven't checked the w3c spec, but at least Liferay Portal seems to require it
> to be encoded)
> The reason is this definition in the UrlEncoder:
> case QUERY :
> // to allow direct passing of URL in query
> dontNeedEncoding.set('/');
> // to allow direct passing of URL in query
> dontNeedEncoding.set('?');
> Currently URL "http://host/file?param=a?b"; would be encoded as
> "http://host/file?param=a?b";, instead of "http://host/file?param=a%3Fb";
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
