Just to follow up on this, thanks for all the good responses.
The solution Grzegorz outlined is probably the best way to do it. Originally
send a post, servlet filter does rewrite service, 301 redirect to short url,
filter comes back in, detects short url and does internal forward to original
request. (I hadn't thought of forward of course, good call there).
But it turns out I really don't have to do any of this. A very very long time
ago during our first beta, we had an issue where IE 6 was caching ajax
responses we obviously did not want it to. I looked at the @HttpCache piece
stripes offered, but for some reason I made the poor decision to trivialize the
cache response headers... We're broken in that every forward is getting these
headers added:
protected ForwardResolution forward(String pageKey) {
HttpServletResponse response = getCtx().getResponse();
response.setHeader("Cache-Control", "no-store, no-cache,
must-revalidate");
response.addHeader("Cache-Control", "post-check=0,
pre-check=0");
response.setHeader("Expires", "Fri, 01 Jan 1990 00:00:00 GMT");
response.setHeader("Pragma", "no-cache");
return new ForwardResolution(lookupPage(pageKey));
}
Obviously that is not right for every type of response. I completely forgot
that piece was hiding in there since it hasn't been touched for over 3 years.
So in reading about proper use of HTTP caching headers, it is really non
trivial. I have to go through every forward and classify case by case how the
caching should work. I'm envisioning 3 or 4 different sets of response headers
depending on how the response should or should not be cached. It's really the
burden of the application developer to make sure caching is handled correctly,
no framework or anything is going to do this for you automatically and get it
right. Anyone sending an http response may want to read
http://www.mnot.net/cache_docs
If I just remove the expires header on this one post, when the user goes back
the page shows up right away.. this is the expected normal experience. So I
was really dead wrong with what I said about IE - it's actually a good feature
on their part to alert that the page has expired. I think the version of FF I
was using did not say anything about page is expired, and just said "do you
want to resend the post?". So once again, our users are unfortunately right
that it is a bug on my end. =)
Thanks again.
-John
-----Original Message-----
From: Grzegorz Krugły [mailto:[email protected]]
Sent: Tuesday, September 27, 2011 13:01
To: Stripes Users List
Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string
parameters?
I think that it's going to have even less of an impact if some of those forms
are used more than once by the same user. You can do 301 permanent http
redirect so the user agent won't hit the original URL with &s more than once
for the same query at least.
Also, I don't think you need Tomcat source code :-) Try something like that:
// check for URL mapping
String rewrittenUrl = ejb.getUrlMapping(req.getRequestURI());
// (...)
if (rewrittenUrl == null) {
chain.doFilter(request, response);
} else {
filterConfig.getServletContext().getRequestDispatcher(rewrittenUrl).forward(request,
response);
return;
}
W dniu 2011-09-27 18:54, Newman, John W pisze:
> Right, I'd strongly prefer one billion requests for a simple task opposed to
> trusting anything from a client. In real life the two requests probably
> isn't a killer.. i'll have to try it out.
>
>
>
> -----Original Message-----
> From: Grzegorz Krugły [mailto:[email protected]]
> Sent: Tuesday, September 27, 2011 12:49 PM
> To: Stripes Users List
> Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query
> string parameters?
>
> It's not possible to bypass the "two requests per one" part if you want the
> URL mangling done server-side. If there's only going to be a single request,
> everything must be done on the client-side. So you'd have to trust their
> clock when timestamping, etc. Not nice at all.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
