Re: Re: Safari caching

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Ralf Ebert
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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&alloc_id865&opclick">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > 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!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wicket-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Igor Vaynberg-2
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.

-Igor


On 1/3/06, Ralf Ebert <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id865&amp;opclick"> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > 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!
<a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id865&amp;opclick">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Johan Compagner
i will see if i can hold on to the header settings in a redirect to buffer.


On 1/4/06, Igor Vaynberg <[hidden email]> 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.

-Igor



On 1/3/06, Ralf Ebert <[hidden email]> wrote:
Hi,

ok, I investigated this a bit further. I just saw Safari caching pages
which have urls like "<a href="http://localhost:8080/xxx_intranet/?path=16" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > <a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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!
<a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/wicket-user


Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Ralf Ebert
Hi,

maybe it would be worth thinking about also adding an abstracted way
to set the cache settings for the client for WebPages which could
default to don't cache at all... Because everytime when the browser
caches without the developer thinking about possible side effects,
something could go wrong...
Nice side effect from disabling the cache for me was that now even on
browser back the side is reloaded from Wicket everytime which feels a
lot more appropiate according to the way Wicket works.

Ralf

On 1/4/06, Johan Compagner <[hidden email]> wrote:

> i will see if i can hold on to the header settings in a redirect to buffer.
>
>
>
> On 1/4/06, Igor Vaynberg <[hidden email] > 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.
> >
> > -Igor
> >
> >
> >
> >
> > On 1/3/06, Ralf Ebert < [hidden email]> 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 < [hidden email]> 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 < [hidden email] > 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!
> > > > > <a href="http://ads.osdn.com/?ad_idv37&alloc_id865&opclick">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > > > > _______________________________________________
> > > > > Wicket-user mailing list
> > > > > [hidden email]
> > > > >
> 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!
> > > <a href="http://ads.osdn.com/?ad_idv37&alloc_id865&opclick">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > > _______________________________________________
> > > Wicket-user mailing list
> > > [hidden email]
> > >
> 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!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wicket-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Johan Compagner
In reply to this post by Johan Compagner
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)

johan


On 1/4/06, Johan Compagner <[hidden email]> wrote:
i will see if i can hold on to the header settings in a redirect to buffer.



On 1/4/06, Igor Vaynberg <[hidden email]> 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.

-Igor



On 1/3/06, Ralf Ebert <[hidden email]> wrote:
Hi,

ok, I investigated this a bit further. I just saw Safari caching pages
which have urls like "<a href="http://localhost:8080/xxx_intranet/?path=16" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > <a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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!
<a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/wicket-user



Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Igor Vaynberg-2
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

-Igor


On 1/4/06, Johan Compagner <[hidden email]> 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)

johan



On 1/4/06, Johan Compagner <[hidden email]> wrote:
i will see if i can hold on to the header settings in a redirect to buffer.



On 1/4/06, Igor Vaynberg <[hidden email]> 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.

-Igor



On 1/3/06, Ralf Ebert <[hidden email]> wrote:
Hi,

ok, I investigated this a bit further. I just saw Safari caching pages
which have urls like "<a href="http://localhost:8080/xxx_intranet/?path=16" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > <a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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!
<a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/wicket-user




Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Johan Compagner
i already have an partial implementation ready.
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 <[hidden email]> 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

-Igor



On 1/4/06, Johan Compagner <[hidden email]> 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)

johan



On 1/4/06, Johan Compagner <[hidden email]> wrote:
i will see if i can hold on to the header settings in a redirect to buffer.



On 1/4/06, Igor Vaynberg <[hidden email]> 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.

-Igor



On 1/3/06, Ralf Ebert <[hidden email]> wrote:
Hi,

ok, I investigated this a bit further. I just saw Safari caching pages
which have urls like "<a href="http://localhost:8080/xxx_intranet/?path=16" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > <a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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!
<a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/wicket-user





Reply | Threaded
Open this post in threaded view
|

Re: Re: Safari caching

Igor Vaynberg-2
nice!
-Igor


On 1/5/06, Johan Compagner <[hidden email]> wrote:
i already have an partial implementation ready.
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 <[hidden email]> 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

-Igor



On 1/4/06, Johan Compagner <[hidden email]> 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)

johan



On 1/4/06, Johan Compagner <[hidden email]> wrote:
i will see if i can hold on to the header settings in a redirect to buffer.



On 1/4/06, Igor Vaynberg <[hidden email]> 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.

-Igor



On 1/3/06, Ralf Ebert <[hidden email]> wrote:
Hi,

ok, I investigated this a bit further. I just saw Safari caching pages
which have urls like "<a href="http://localhost:8080/xxx_intranet/?path=16" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 <[hidden email]> 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 <[hidden email]> 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!
> > <a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-user mailing list
> > [hidden email]
> > <a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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!
<a href="http://ads.osdn.com/?ad_idv37&amp;alloc_id%16865&amp;opclick" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/wicket-user" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/wicket-user