You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jeff Poetker <je...@gmail.com> on 2004/08/25 18:00:25 UTC
Question about URL Rewriting
We're using Tapestry with Weblogic 8.1 and I was wondering how well it
supports URL Rewriting for browsers who will not accept cookies.
The first problem I found was in the RedirectFitler which does not
seem to run the url through the HttpServletResponse.encodeRedirectURL
method.
Once I got past that by implementing my own filter, I was able to
login (we are using the J2EE form based authentication). And the app
displayed, sort of, and the various links in our application seem to
be functional, which makes me think some care was taken to use
encodeURL.
However, let me explain the sort of part. My private assets were not
downloaded - no images or css. Which leads me to believe that asset
service is not encoding the URLs. I imaging this may not be an issue
if we had the static assets dumped out for the webserver to serve, and
we are planning on using that feature in production, however, we
weren't planning on configuring it on our individual developer boxes.
Has anybody else tried out URL rewrting (by not accepting cookies)?
I'm wondering what your experiences were, and if maybe I overlooked
something.
Thanks,
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Question about URL Rewriting
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Paul Ferraro had a post on July 26 describing his whole URL rewriting
scheme. The Subject line is:
Re: Another Tapestry-driven web site launched
Jamie
----- Original Message -----
From: "Jeff Poetker" <je...@gmail.com>
To: <ta...@jakarta.apache.org>
Sent: Wednesday, August 25, 2004 12:00 PM
Subject: Question about URL Rewriting
> We're using Tapestry with Weblogic 8.1 and I was wondering how well it
> supports URL Rewriting for browsers who will not accept cookies.
>
> The first problem I found was in the RedirectFitler which does not
> seem to run the url through the HttpServletResponse.encodeRedirectURL
> method.
>
> Once I got past that by implementing my own filter, I was able to
> login (we are using the J2EE form based authentication). And the app
> displayed, sort of, and the various links in our application seem to
> be functional, which makes me think some care was taken to use
> encodeURL.
>
> However, let me explain the sort of part. My private assets were not
> downloaded - no images or css. Which leads me to believe that asset
> service is not encoding the URLs. I imaging this may not be an issue
> if we had the static assets dumped out for the webserver to serve, and
> we are planning on using that feature in production, however, we
> weren't planning on configuring it on our individual developer boxes.
>
> Has anybody else tried out URL rewrting (by not accepting cookies)?
> I'm wondering what your experiences were, and if maybe I overlooked
> something.
>
> Thanks,
> Jeff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Question about URL Rewriting
Posted by Jeff Poetker <je...@gmail.com>.
Agreed, I've been digging a little bit more, and have come to the same
conclusion.
I think the simple solution is not to use private assets, which
shouldn't be a problem for us. And I've already created a new
redirect filter that will encode the url correctly.
I too wonder about the necessity of the stateful parameter in the
EngineServiceLink. I would think always encode it, but I've always
been under the impression that the servlet container knew if it was
really needed or not. That may be an invalid assumption on my part.
Thanks for the response, I'm glad to hear that somebody is using
tapestry without cookies in several apps, maybe I've run into the only
2 problems. :)
On Wed, 25 Aug 2004 10:14:00 -0700, Paul Ferraro <pm...@columbia.edu> wrote:
> I am using Tapestry without the cookies for several applications,
> however, these applications do not use RedirectFilter, nor do I ever use
> private assets.
>
> The RedirectFilter issue looks like an oversight. Its original
> intention was to handle the initial request to a web application, just
> as web application welcome-file-list entries do, but it incorrectly
> assumes that no session is present.
>
> Your issue with private assets is definitely a bug. After digging
> through the AssetService class, you'll find the culprit on line 94.
>
> return constructLink(cycle, Tapestry.ASSET_SERVICE, null,
> parameters, false);
>
> The last parameter to the constructLink() method indicates whether or
> not the link is "stateful". This value is eventually used by the
> EngineServiceLink class to indicate whether or not to use
> response.encodeURL() to rewrite the generated URL. Aha!
>
> The obvious fix is change line 94 to the following:
>
> return constructLink(cycle, Tapestry.ASSET_SERVICE, null,
> parameters, true);
>
> However, perhaps the more thorough fix is to remove the "stateful"
> parameter from the EngineServiceLink constructor and either always
> encode the url, or only encode the url if cycle.getEngine().isStateful()
> returns true.
>
> Thoughts?
>
> Paul
>
>
>
> Jeff Poetker wrote:
>
> >We're using Tapestry with Weblogic 8.1 and I was wondering how well it
> >supports URL Rewriting for browsers who will not accept cookies.
> >
> >The first problem I found was in the RedirectFitler which does not
> >seem to run the url through the HttpServletResponse.encodeRedirectURL
> >method.
> >
> >Once I got past that by implementing my own filter, I was able to
> >login (we are using the J2EE form based authentication). And the app
> >displayed, sort of, and the various links in our application seem to
> >be functional, which makes me think some care was taken to use
> >encodeURL.
> >
> >However, let me explain the sort of part. My private assets were not
> >downloaded - no images or css. Which leads me to believe that asset
> >service is not encoding the URLs. I imaging this may not be an issue
> >if we had the static assets dumped out for the webserver to serve, and
> >we are planning on using that feature in production, however, we
> >weren't planning on configuring it on our individual developer boxes.
> >
> >Has anybody else tried out URL rewrting (by not accepting cookies)?
> >I'm wondering what your experiences were, and if maybe I overlooked
> >something.
> >
> >Thanks,
> >Jeff
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Question about URL Rewriting
Posted by Paul Ferraro <pm...@columbia.edu>.
I am using Tapestry without the cookies for several applications,
however, these applications do not use RedirectFilter, nor do I ever use
private assets.
The RedirectFilter issue looks like an oversight. Its original
intention was to handle the initial request to a web application, just
as web application welcome-file-list entries do, but it incorrectly
assumes that no session is present.
Your issue with private assets is definitely a bug. After digging
through the AssetService class, you'll find the culprit on line 94.
return constructLink(cycle, Tapestry.ASSET_SERVICE, null,
parameters, false);
The last parameter to the constructLink() method indicates whether or
not the link is "stateful". This value is eventually used by the
EngineServiceLink class to indicate whether or not to use
response.encodeURL() to rewrite the generated URL. Aha!
The obvious fix is change line 94 to the following:
return constructLink(cycle, Tapestry.ASSET_SERVICE, null,
parameters, true);
However, perhaps the more thorough fix is to remove the "stateful"
parameter from the EngineServiceLink constructor and either always
encode the url, or only encode the url if cycle.getEngine().isStateful()
returns true.
Thoughts?
Paul
Jeff Poetker wrote:
>We're using Tapestry with Weblogic 8.1 and I was wondering how well it
>supports URL Rewriting for browsers who will not accept cookies.
>
>The first problem I found was in the RedirectFitler which does not
>seem to run the url through the HttpServletResponse.encodeRedirectURL
>method.
>
>Once I got past that by implementing my own filter, I was able to
>login (we are using the J2EE form based authentication). And the app
>displayed, sort of, and the various links in our application seem to
>be functional, which makes me think some care was taken to use
>encodeURL.
>
>However, let me explain the sort of part. My private assets were not
>downloaded - no images or css. Which leads me to believe that asset
>service is not encoding the URLs. I imaging this may not be an issue
>if we had the static assets dumped out for the webserver to serve, and
>we are planning on using that feature in production, however, we
>weren't planning on configuring it on our individual developer boxes.
>
>Has anybody else tried out URL rewrting (by not accepting cookies)?
>I'm wondering what your experiences were, and if maybe I overlooked
>something.
>
>Thanks,
>Jeff
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org