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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
