On 05.09.2017 22:42, Thomas, Michael wrote:
----------------------------------------------------------------------
On 01.09.2017 22:21, Thomas, Michael wrote:
All,
When using the ISAPI Handler Mapping in IIS 10 on Windows 2016, the IIS logs are not
identifying the URI Stem (cs-uri-stem) and URI Query (cs-uri-query) as expected. For
EVERY request that the handler processes (e.g. .cfm), the cs-uri-stem records an entry as
"/jakarta/isapi_redirect.dll" and the cs-uri-query is always empty.
Environment Details:
* IIS 10 (Windows 2016)
* Tomcat 8.5.11.0
* Java 1.8.0_131
* ISAPI Connector 1.2.41
* ColdFusion 2016
For comparison, we have a similar setup on another box (IIS 8.5 Windows Server
2012 R2) and the logs are recording as expected.
Any assistance would be great!
----------------------------------------------------------------------
On 01.09.2017 22:37, Warnier, Andre wrote
Hi.
If I understand this correctly, the difference between your two setups above is
at the Windows/IIS level, not at the tomcat/ISAPI-redirector level.
This may be naive, but isn't this a question then for the Windows/IIS people ?
----------------------------------------------------------------------
Andre, you're right. Perhaps this is a good question for the Windows folks. I
guess I was hoping that someone in this community has seen this issue before
and had a recommended solution.
It is really challenging to not know what traffic your IIS Web Server is
actually seeing. There are of course other avenues (e.g. firewall logs, siem
logs, etc) but the IIS logs are native to the boxes themselves and much easier
to analyze. I was curious if the ISAPI Connector returned a specific URL back
to IIS and it could be tweaked. Not sure if IIS is expecting a response in a
certain format, etc.
Is there documentation that I can look at for what the ISAPI module should
return to IIS? Anyone have any insight into that pipeline?
First, about your last question above : I don't know, and I guess that the right people
for that on this list would be Rainer or Mladen.
But second, I believe that the terminology you are using above is a bit confusing, from
the point of view of the logic of the thing, particularly when you mention "what the ISAPI
module should return to IIS".
IIS is the front-end, and it gets the client HTTP request first (URL, headers
and all).
So it /has/ all the information needed to log whatever, should it choose to do
so (*).
In a second step, IIS examines the request URL and, maybe with the help of the
isapi_redirector, it determines that to properly answer this request, it should not use
its own internal machinery, but it should delegate this to the isapi_redirector module.
What the isapi_redirector module does with the request, is none of IIS's business, so to
speak. The only thing which IIS expects back from the isapi_redirector module, is either a
HTTP succesful response, or some error code.
So this is the only additional information for which IIS might be waiting, for logging the
request (e.g. the size of the response, and/or the time needed to generate it).
That the isapi_redirector module, to generate this HTTP response, uses a back-channel with
a back-end tomcat, is unknown to IIS, and it does not care. From the IIS point of view,
isapi_redirector might as well be using black magic to generate that response internally,
without ever talking to anyone else.
(*) but in your case, it doesn't do it, or does it differently than IIS 8.5 or whatever
earlier version did, although all the rest of the machinery did not change. So /that's/
the mystery to solve. Maybe MS changed the rules of the game (the ISAPI interface) somehow
for IIS 10, and an ISAPI module is now supposed to do something additional, to get things
properly logged, that the ISAPI-redirector module does not do (yet).
But I think that you are still more likely to get that kind of information on an
IIS-oriented forum, that on this tomcat forum.
I would ask first for example, for any IIS-10 specific changes in the logging of requests,
maybe in conjunction with the usage of ISAPI filters in general.
(Maybe it is just your log formatting that does not invoke the right items of
information ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
