 |
 |
As promised, I poked around Cocoon a bit to see how it would handle Walter's scenario of propagating cookies. As near as I can tell, there should be a way of working with session contexts to do this, but when I couldn't connect to the Apache site last night I decided to make a small application in Cocoon to catch the cookies and append them to the content. I used the existing HTML generator and added some small cookie handling logic. Since I was using the merging capabilities of Cocoon to lump all the pages together coming in this way, I set up a test that uses the parallel and caching options. If you use any of these three URLs, you might be able to detect some differences in responses. Sorry, I didn't set up a stylesheet so everything is thrown together in one big jumble. Our general internet connectivity is so bad right now that it probably overshadows everything else but the different configurations are in brackets beside each URL: http://137.207.184.118:8080/cocoon/wibs/cinclude-test1 (multiple pages in sequence) http://137.207.184.118:8080/cocoon/wibs/cinclude-test2 (multiple pages in parallel) http://137.207.184.118:8080/cocoon/wibs/cinclude-test3 (multiple pages in parallel with caching) You will probably need to do a view source to make any sense of the results, but pages that have cookies will have "cookie" elements with the value of the cookie making up the node. The first section is from the Privacy Commissioner of Canada and I had to include it because it seems so ironic that this page uses cookies! The other pages are google, dmoz, and lii. You could also add your own cookies with this method, or override the existing ones before handing them over to a user. The cookie handling capabilities of httpclient, which is used here, allows you to set different cookie policies, and I am using the default policy. I noticed that this rejects the first cookie from google if you use the "www.google.ca" address since the cookie actually comes from "www.google.com". I assume there are more forgiving policies for this kind of thing. Anyway, I can share the files if someone wants to dive deeper into this. My general experience is that someone will point out the way to do this that doesn't require coding at the precise moment that I resort to programming because I can't figure it out directly. So it's possible that the added piece is not even necessary. Cocoon uses JTidy for converting HTML to XHTML, and one thing I learned in this process is that this can be configured fairly deeply. If you look at the source of the rendered page you will see that the jump from HTML to XHTML is not without some quirks and this would need some tinkering to handle the different interfaces. art