Now there will be no difference for a WebPage when it is rendered. It will always be a WebResponse (people where complaining that sometimes it is
not a webresponse and then they also can't get the httpservletresponse when the need it)
i now replace it with just a WebResponse but with oure own (Buffered) implementation of a HttpServletResponse object.
So that form the developers point of view there is no change what so every. And everything including cookies/headers will be set.
johan
On 1/4/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
thats why i said maybe we should provide a datastructure just for this instead of letting the user mock response objects.
something like Headers getHeaders() in the page and Headers has addHeader(..). that way we can store it with the buffered response or output it based on the render strategy
-IgorOn 1/4/06, Johan Compagner < [EMAIL PROTECTED]> wrote:hmm i checked this.
But what is currently the preferred way to set response headers in Page.configureResponse()?
check if the Response object is a WebResponse? And then call there setHeader(String,String)?
Or even call webResponse.getHttpServletResponse()
and do it directly in there?
Then i think in redirect_to_buffer i will not set a BufferedResponse object but a WebResponse but with
a implementation of a HttpServletResponse object (where we do all the caching of the date that we get with write or setHeaders)
johanOn 1/4/06, Johan Compagner < [EMAIL PROTECTED]> wrote:i will see if i can hold on to the header settings in a redirect to buffer.On 1/4/06, Igor Vaynberg <[EMAIL PROTECTED] > wrote:maybe we need to rethink how we allow users to set headers. the redirect_to_buffer is broken because it just spits out the buffer w/out the headers that were set on the page, so it doesnt really record the entire state. it is worse because it is our default render strategy.
somehow we need to record the headers the user wants to add for a page and also set them when we dump the buffer in redirect_to_buffer. this is why configureresponse() is broken.
maybe instead of allowing the user to push the headers into the response we push them into some kind of datastructure that we store in the response buffer.
does anyone have time to look into this right now? im busy with the settings refactor.
-IgorOn 1/3/06, Ralf Ebert < [EMAIL PROTECTED]> wrote:Hi,
ok, I investigated this a bit further. I just saw Safari caching pages
which have urls like "http://localhost:8080/xxx_intranet/?path=16"
without taking the session into account. This was the reason for the
odd behaviour my users got sometimes (clicking on links that just were
not in the page component tree). I fixed it for my application using a
servlet filter like this:
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
HttpServletResponse httpServletResponse = (HttpServletResponse) response;
httpServletResponse.setHeader("Pragma","no-cache");
httpServletResponse.setHeader ("Cache-Control","no-store, no-cache,
max-age=0, must-revalidate");
chain.doFilter(request, response);
}
configureResponse didn't helped with that because not all responses
handled by wicket would have the header (I didn't checked, but Safari
still cached using configureResponse; it doesn't using the Filter).
I'm not sure how browser caches should work for these kind of urls,
but in my opinion a browser should cache nothing that has request
parameters... But I think this can lead to strange problems and Wicket
should try to prevent these things happening... Maybe by setting the
headers itself (which would make sense for pages in my opinion) or by
doing something with the url which prevents caching the same page ever
(which would cause even more url ugliness :)
Regards,
Ralf
On 12/23/05, Johan Compagner < [EMAIL PROTECTED]> wrote:
> can you tweak header cache settings somehow?
> configureResponse of page and then using a WebResponse object.
> The problem is if you use redirect_to_buffer you don't have a webresponse
> object when rendering i think.
> So you can't really set the headers currently
>
> johan
>
>
>
> On 12/22/05, Ralf Ebert < [EMAIL PROTECTED] > wrote:
> >
> > Hi,
> >
> > I tried to investigate this problem a bit further after a user
> > complaining about a bug which seems to be related to this (I found
> > exceptions in the log like "No component found for 1:xxx:3:linkYyy").
> > This is very strange, Safari caches all pages which only have a
> > ?path=xxx page (when going back to them it doesn't reload), but it
> > reloads all pages which have urls like ?bookmarkablePage=xxx. I cannot
> > explain this, both have only one request parameter... Setting no-cache
> > headers or meta-tags doesn't help at all. I'm a bit stuck with this
> > one, especially because it seems to happen not only when using the
> > back button... Any ideas (except using Firefox) :) ?
> >
> > Ralf
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
