tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: AW: mod_jk and session stickyness of images requests
Date Tue, 15 Dec 2009 20:04:10 GMT
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Timo,
> 
> On 12/15/2009 8:36 AM, Kockert, Timo wrote:
>> - We enabled session cookies and URL rewriting (the latter via
>> EncodeUrlTransformer of Cocoon).
> 
> Oh, and what version of Cocoon are you using?
> 
I believe that I saw pass, a few posts ago, something about Cocoon 
seeing a cookie, and thus deciding not to do URL-rewriting for the links 
in the current response.

Let me very hypothetically suggest a scenario :

- some user agent out there has a bug, with the consequence that for 
<img ..> links embedded in a page, it does not send cookies with the 
corresponding requests.
But for html pages it does.
(*)

- at the server side, to accomodate both agents that can handle cookies 
and agents that cannot, in principle the setup is to do both : send a 
session-id cookie, but also do URL-rewriting and add a ";jsessionid" 
attribute to the URLs.

- However Cocoon interferes with that setup, in the sense that when it 
gets a request with a cookie, it does not do the rewriting of the URLs 
embedded in the response page; instead it just responds with a 
Set-Cookie header.

- so now the user-agent gets a response html page, in which the embedded 
img links have not been rewritten, and thus do not contain the 
";jesssionid.." attribute.
When it requests these images, the URLs for said requests do not contain 
the jsessionid attribute; and because of the aforementioned bug, it does 
not send a cookie either.

I know it is kind of a bizarre bug for an agent, but it seems to fit the 
symptoms. Once you have eliminated the impossible, what remains, however 
improbable, must be the truth.

One way of checking this would be to log, at the server level, the 
request URLs together with the corresponding HTTP headers (**).
If you see a request for an image come in, without a ";jsessionid" 
attribute in the URL, AND without a "Cookie: JSESSIONID", then it must 
be so.



(*) Note that this is why, early in the cycle, I specifically asked if 
the images were being requested by some separate applet or Javascript 
thingie, rather than a simple <img> link.
That is because it might have explained why the "main" request, for a 
page, may have contained a Cookie, but the <img> requests not.

(**) or use Wireshark, and filter for HTTP requests fitting the image 
pattern.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message