It looks like LiftRules.urlDecorate may be what I'm looking for, but
combing through net.liftweb.http.Req and net.liftweb.http.S, I'm at at
a loss for what to change it to, or how it even gets used by
Req._fixHref when updating the URLs. I'm reluctant to start changing
LiftRules.urlDecorate to my own URLDecoratorPF based on the code
comment about it being used for Ajax requests. I'm not wanting to
cause any more of a mess than necessary.
>From what I can tell, Req._fixHref is where the URLs are actually
being rewritten. The only test I see in here that may be of any use
to me is "rewrite.isDefined" which refers to URLRewriter.rewriteFunc.
S.encodeURL is where this seems to be set:
----------- S.scala ----------
def encodeURL(url: String) = {
URLRewriter.rewriteFunc map (_(url)) openOr url
}
I feel like I've missed the code that adds the jsessionid to the
URLRewriter object somewhere, so maybe there is another LiftRule that
will let me shut this off.
Beyond my still wanting to disable this specific URL rewriting within
Lift, what I have found about using jsessionid in URLs leads me to
believe that there may be a bug here somewhere. See if I have this
right:
When a client (browser) connects, the servlet container doesn't know
if cookies are enabled. It sets a session cookie on the response, and
also rewrites path URLs to include ;jsessionid=yourSessionId. If the
browser has cookies disabled, on the second request the server will
find jsessionid on the end of request URL which is will use to
maintain an active session (not very secure, but that's another
story). It then rewrites the URL without the jsessionid parameter and
forwards it on to the appropriate context for further handling.
What I'm seeing is that when a client has cookies enabled, the server
is not stripping the jsessionid from the requested URI if it refers to
a resource other than one handled by Lift directly (ie *.html ). For
other file types the server is failing to rewrite the URL
without ;jsessionid=uniqueid which is leading to 404 errors when
looking for things like .m4v .jpg etc.
Can someone else verify this?
Grant
On Sep 18, 2:43 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> Lift is inserting these are part of the URL rewriting at the request of the
> container.
>
> Is this causing a problem? If it is, you can disable it... I forgot how,
> but I can dig through the code to find out the appropriate LiftRules to
> change.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
