Alright,
Unfortunately there's no way (that I have found) to get IIS to actually
log what it's passing off to the connector, but in my testing I do think
I discovered what the key factor is.
Whenever I get this line:
[debug] HttpFilterProc::jk_isapi_plugin.c (1932): [/myfile] is a servlet
url - should redirect to ajpfilter
Things go great. The header information contains the proper cookie line,
and everything works like it should.
However, whenever I see this in the logs:
[debug] HttpFilterProc::jk_isapi_plugin.c (2055): [/] is not a servlet url
(This is because I have IIS configured with a default document and a
script map, thus no file name is actually present in the URL) The cookie
header is NOT present in the request that the connector passes off to
Tomcat. This is when life sucks.
I can add a /*=ajp13 to the uriworkermap, and have it work because then
the connector has the "this is a servlet url" in the logs, but without
that "global" mapping, no cookie information is passed along.
I'm not sure if this is something that can be controlled via the
connector, but seeing as it is something that works fine when it's a
servlet URL, it seems like something that SHOULD work when it's NOT a
servlet URL.
Does this make any sense? Should I file a bug report?
Thank you for your help!
Warm regards,
Jordan Michaels
Vivio Technologies
http://www.viviotech.net/
Open BlueDragon Steering Committee
Railo Community Distributions
Rainer Jung wrote:
On 05.04.2010 18:35, Jordan Michaels wrote:
Okay, I will try that. I have the properties log level currently set to
"debug". I'll try trace and see if it can provide more information there
(I didn't realize trace had more information then debug).
Trace adds log lines for entering and leaving functions (not so
interesting for you) but also switches from logging only the first
couple of bytes in each raw AJP packet to dumping the full packet
contents to the log file. It is a raw packet dump though, but since the
cookie headers are strings, they can be recognized in the packet dump
relatively easily. Try with a request which does send the cookie first,
so you know what to look after.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
