all page URLs appended with ;jsessionid=knq01t90ajh7

1,285 views
Skip to first unread message

Grant Wood

unread,
Sep 18, 2009, 2:47:13 PM9/18/09
to Lift
The first time a browser visits my site, all the path-only URLs
embedded in the requested page are being appended with what looks like
a malformed query parameter containing the session id.

for example:
<a href="/correct/path/" >link</a>
is being rewritten:
<a href="/correct/path/;jsessionid=knq01t90ajh7" >link</a>

What's odd is that it is also happening to <img> elements as well:
<img src="/s/images/site/light_blue.png" />
is being rewritten:
<img src="/s/images/site/light_blue.png;jsessionid=knq01t90ajh7" /
>

This happens reliably if you clear the cache and all session data from
your browser and visit any page in the site first. ANy subsequent
pages are fine. The result is that links work fine (which is why I
didn't notice the problem right away) but images and embedded media
are broken. If you reload the page, the URLs are all fine.

The ;jsessionid=<session id>

Other facts:
- It is NOT affecting URLs in CSS or js in external files.

- It is NOT being added to URLs with a protocol and authority such
as:
http://www.foo.com/path/to/page (and it makes no difference if
its an external link or not)

- I first suspected that a script somewhere was doing this, however,
disabling javascript in the browser causes no change. I verified this
using curl.. the URLs are being altered on the server.

- I'm on the latest 1.1-SNAPSHOT, but this has been happening for some
time, possibly since I started my work on lift 6 weeks ago.


I have been searching through lift code for jsessionid without luck,
so hopefully David or someone knows exactly what part of the chain is
causing this. Its certainly possible I'm doing this somehow, but I
can find nothing that would come close to doing this in any of my
snippets (or models or libs for that matter)

Thanks for any insight, let me know what other information would be
helpful.

Chris Lewis

unread,
Sep 18, 2009, 3:15:22 PM9/18/09
to lif...@googlegroups.com
It has nothing to do with lift, but the servlet container. "jsessionid"
is a specified standard, and appending it I *think* is part of the
mandate when implementing the servlet api. That is to say, the automatic
appending will probably occur on any servlet container. Google around
and you'll find various ways people deal with it.

David Pollak

unread,
Sep 18, 2009, 3:43:45 PM9/18/09
to lif...@googlegroups.com
On Fri, Sep 18, 2009 at 12:15 PM, Chris Lewis <burning...@gmail.com> wrote:

It has nothing to do with lift, but the servlet container. "jsessionid"
is a specified standard, and appending it I *think* is part of the
mandate when implementing the servlet api. That is to say, the automatic
appending will probably occur on any servlet container. Google around
and you'll find various ways people deal with it.

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.
 



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

marius d.

unread,
Sep 18, 2009, 5:03:14 PM9/18/09
to Lift
Turning ON cookies in container will disable URL rewriting. jsessionid
will become a cookie.

Br's,
Marius

On Sep 18, 2:43 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> Beginning Scalahttp://www.apress.com/book/view/1430219890

Atsuhiko Yamanaka

unread,
Sep 18, 2009, 8:04:26 PM9/18/09
to lif...@googlegroups.com
Hi,

On Sat, Sep 19, 2009 at 4:43 AM, David Pollak
<feeder.of...@gmail.com> wrote:
>
>
> 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.

I had troubles.
For example,
<a href="#" onlick="...">click</a>
was suddenly transformed to
<a href=";jsessionid=knq01t90ajh7#" onlick="...">click</a>
and the page reload was happened unexpectedly.

Now, I have rewritten those anchor tags as
<a href="javascript:void(0)" onclick="...">click</a>
and such troubles have disappeared. So, it is not a problem for me anymore.
This is just FYI.


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/

marius d.

unread,
Sep 18, 2009, 10:46:27 PM9/18/09
to Lift
LIft doesn't explicitly add jsessionid to the URL but it calls
encodeUrl on the HttpServletResponse. If in the container you have the
cookies turned off URL rewrite comes into picture. This is because we
need lift apps to still work when cookies are turned off from
container. This is the correct behavior.

Your specific example sounds like a bug and I'll try to fix it
tomorrow.

Br's,
Marius

On Sep 18, 7:04 pm, Atsuhiko Yamanaka <atsuhiko.yaman...@gmail.com>
wrote:
> Hi,
>
> On Sat, Sep 19, 2009 at 4:43 AM, David Pollak
>

Grant Wood

unread,
Sep 19, 2009, 12:16:56 AM9/19/09
to Lift
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:

Grant Wood

unread,
Sep 19, 2009, 1:09:36 AM9/19/09
to Lift
Atsuhiko's experience makes sense if you look in Req.

_fixHref is where the rewriting is actually happening:
--------------- Req ...
private def _fixHref(contextPath: String, v : Seq[Node], fixURL:
Boolean, rewrite: Box[String => String]): Text = {
val hv = v.text
val updated = if (hv.startsWith("/")) contextPath + hv else hv

Text(if (fixURL && rewrite.isDefined &&
!updated.startsWith("mailto:") &&
!updated.startsWith("javascript:") &&
!updated.startsWith("http://") &&
!updated.startsWith("https://"))
rewrite.open_!.apply(updated) else updated)
}
... Req ---------------

Lift is skipping the rewrite if the attribute startsWith
("javascript:") but if it starts with # it will be rewritten.
This would be an easy fix: !updated.startsWith("#") &&
I suspect this change would meet most developers behavior
expectations.

If a client is not using cookies and requires :jsessionid=theSessionId
to be appended, this test will also fail to properly rewrite fully
qualified URLs with the http or https protocol that have the same
hostname (S.hostName) as the authority section. Someone with a better
handle on the Servlet and Servlet Container spec will have to chime in
and determine whether there are rules governing this situation.

Does anybody know if rewrite: Box[String => String] being used by
anything other than the jsessionid rewrite?


- Grant

marius d.

unread,
Sep 19, 2009, 11:54:26 AM9/19/09
to Lift
I just committed the fix.

Box[String => String] is calling URLRewriter which holds the function
that does URL manipulation. This is set in HTTP Provider. It does 2
things:

- calls encodeURL
- calls URLDecorator

URLDecorator is important in case one wants to add something to all
URL's. For instance in case of sticky sessions, load balancers need to
know where to balance a request and this is done by various policies:

- JSESSIONID affinity
- URI based balancing (here URLDecorator makes a lot of sense as load
balancers can determine where to balance requests based on a query
string parameter)

Other notes about your comments"

"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. " -
Server does not rewrite URLs if container's cookies are turned ON.
This decision is done by the container and not Lift. So you either
have JSESSIONID as a cookie or as part of the URL aka URL rewriting.



Br's,
Marius

Lee Mighdoll

unread,
Sep 19, 2009, 4:15:03 PM9/19/09
to lif...@googlegroups.com
For jetty, you might also try the following inside your web.xml <webapp> section:

  <context-param>
    <param-name>org.mortbay.jetty.servlet.SessionURL</param-name>
    <param-value>none</param-value>
  </context-param>

see:  http://docs.codehaus.org/display/JETTY/SessionIds

Lee

Reply all
Reply to author
Forward
0 new messages