Your web server is appending the SID to the images (and would to other
links to the same webapp in the page) to track sessions, and is a
common technique used by webservers to support sessions when browser
clients don't support cookies.

I'm a little fuzzy on how exactly this works because it "Just Works",
and some of the "old salts" on the list could probably explain it
better, but here's what I think is happening. Some background, when a
session-based request comes in, it sees if the client has also sent a
cookie for the session. If not, assumes that the client does not have
cookies enabled, so appends the session id to every link so that
requests can be matched to sessions. For your situation, in the first
request, a session is created, and since there will be no cookie from
the client because it's a new sesion, the resposne to the client will
include a cookie and a session id on links because the server cannot
know if cookies are accepted or not. Why you don't see it after the
first request is because after the first request the client is
returning the session ID cookie.

There is probably a much better discusson of how this works elsewhere,
maybe at the Tomcat website. Also, I'm not sure what web server you're
using, most use jsessionid; you could try searching for that on the
list.

You might be able to get around this by specifying a redirect=true for
this initial page.
-ed

On 11/17/05, Aladin Alaily <[EMAIL PROTECTED]> wrote:
> Hmmm... that's interesting.
>
> It looks as though I have no control on whether or not the SID is
> appended.  The first time my page is loaded, the SID is appended and the
> images & links don't resolve.  If I reload the page, the SID are removed
> and everything resolves.
>
> I am using Tomcat 5.5.12 and the following jars & tlds:
>
> struts-1.2.7.jar
> commons-beanutils-1.7.0.jar
> commons-collections-3.1.jar
> commons-digester-1.7.jar
> commons-logging-api-1.0.4.jar
> standard-1.1.2.jar
>
> servlet-api.jar -> Tomcat's
> jsp-api.jar     -> Tomcat's
>
> struts-bean-1.1.tld
> struts-html-1.1.tld
> struts-logic-1.1.tld
> struts-nested-1.1.tld
> c-1.1.2.tld
>
>
> Aladin
>
>
> > It works for me.
> >
> > I would guess that this is pretty standard HTTP to be
> > honest. It should resolve the images by stripping off
> > any unnecessary SID info' etc, if you don't use it for
> > security checking for example. I thought that the
> > requests for images are exactly the same as a request
> > for any other resource, ie, a standard HTTP request
> > and therefore the SID is appended unless you
> > explicitly turn it off. Your web server should
> > resoplve the path of the url whether or not there is a
> > SID attached.
> >
> > --- Aladin Alaily <[EMAIL PROTECTED]> wrote:
> >
> >> That's not normal...  If you add the semi-colon and
> >> the jsessionid to an
> >> image src, then the image is not going to resolve
> >> properly.  That's the
> >> behaviour that I'm noticing - with the jsessionid,
> >> the links & images
> >> don't resolve.
> >>
> >> Aladin
> >>
> >>
> >>
> >> > That's normal. What's wrong with that?
> >> >
> >> > --- Aladin Alaily <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I am using <html:img> and <html:link> tags but
> >> when
> >> >> they are evaluated a
> >> >> jsessionid is appended:
> >> >>
> >> >> Image Example:
> >> >> --------------
> >> >> <html:img page="/images/x.gif" height="10"
> >> width="1"
> >> >> />
> >> >>
> >> >> GIVES
> >> >>
> >> >> <img
> >> >>
> >> >
> >>
> > src="/images/x.gif;jsessionid=1F69046A7709D30FD9AC36FC6E8A4336"
> >> >>
> >> >> height="10" width="1">
> >> >>
> >> >> Link Example:
> >> >> -------------
> >> >> <link href="<html:rewrite page="/css/styles.css"
> >> />"
> >> >> rel="stylesheet"
> >> >> type="text/css">
> >> >>
> >> >> GIVES
> >> >>
> >> >> <link
> >> >>
> >> >
> >>
> > href="/css/styles.css;jsessionid=1F69046A7709D30FD9AC36FC6E8A4336"
> >> >>
> >> >> rel="stylesheet" type="text/css">
> >> >>
> >> >> Has anyone experienced this before?  If so, how
> >> did
> >> >> you fix this problem.
> >> >>
> >> >> I am using struts 1.7
> >> >>
> >> >> Thanks.
> >> >> Aladin
> >> >>
> >> >>
> >> >
> >>
> > ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail:
> >> >> [EMAIL PROTECTED]
> >> >> For additional commands, e-mail:
> >> >> [EMAIL PROTECTED]
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> > ___________________________________________________________
> >> > Yahoo! Messenger - NEW crystal clear PC to PC
> >> calling worldwide with
> >> > voicemail http://uk.messenger.yahoo.com
> >> >
> >> >
> >>
> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail:
> >> [EMAIL PROTECTED]
> >> > For additional commands, e-mail:
> >> [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >>
> >>
> > ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> [EMAIL PROTECTED]
> >> For additional commands, e-mail:
> >> [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >
> >
> >
> > ___________________________________________________________
> > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
> > voicemail http://uk.messenger.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to