On 15.12.2009 14:36, Kockert, Timo wrote:
Thanks for all your answers so far! I'm still trying to figure out the problem 
but there are also some other things I need to take care of.

Just to make it clear, here is a summary of my problem and what was suggested 
so far:

- We have a webapp that serves content (html, xhtml, ...) and images (jpg, png, 
...).
- Both, content and images, are _not_ static.
- They are generated by two different servlets in the same context.
- The images are generated _only_ on the server that processed the content 
request.
- This means subsequent image requests have to be routed to the same server as 
the content request.
- We enabled session cookies and URL rewriting (the latter via 
EncodeUrlTransformer of Cocoon).
- The cookie path is equal to the context path, so the cookies are valid for 
both servlets (content and images).
- In general the whole mod_jk load balancing works fine, with or without 
cookies (I tried disabling cookies on my iPhone and it worked as expected).
- Some devices however don't seem to send cookies with image requests, although 
they send a valid cookie with the previous content request.

And do they use a URL with encoded session to retrieve the images? If the link was encoded correctly, they should. You can easily check by looking at the existing access log. Or does cocoon no longer encode the session in the URL, if it sees the cookie in the previous request?

- The latter may or may not be a problem of the devices themselves or an 
intermediate proxy or something else (we already had a problem with BlackBerry 
servers killing sessions).

I have yet to try what Rainer suggested: adding the cookie information to the 
access log. The problem was, that we need the access logs for statistics and I 
didn't know (till Christopher wrote it), that we could set up a secondary log. 
Once I have that running, I might be able to give more details.

Greetings,
Timo

Regards,

Rainer

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

Reply via email to