tracker issue : CF-4199631

select a category, or use search below
(searches all categories and all time range)
Title:

All CFM requests logged as /jakarta/isapi_redirect.dll in IIS 10.0

| View in Tracker

Status/Resolution/Reason: To Track//ThirdParty

Reporter/Name(from Bugbase): e-domizil License Team / e-domizil License Team ()

Created: 09/08/2017

Components: connector

Versions: 2016

Failure Type: Data Loss

Found In Build/Fixed In Build: Updater 4 /

Priority/Frequency: Normal / All users will encounter

Locale/System: ALL / Win 2012 Server x64

Vote Count: 1

Problem Description: 

If ColdFusion ist installed on Windows 2016 every request is logged as "/jakarta/isapi_redirect.dll" and not with the real URL like before in Windows 2012 R2 and earlier.

Steps to Reproduce:

1. Install Windows 2016 with IIS and ColdFusion
2. Request CFML file
3. Review the IIS log.

Actual Result:

- IIS logs are full of "/jakarta/isapi_redirect.dll" only. Logs cannot exaimined for security issues and visitors behavior. 

Expected Result:

- Correct log entry.

Any Workarounds:

- None are known as of today

Attachments:

Comments:

Already discussed in https://forums.adobe.com/thread/2245949
Comment by Alexander H.
351 | September 08, 2017 03:46:33 PM GMT
Any updates?
Comment by Michael T.
352 | September 19, 2017 12:29:56 PM GMT
I have been asked by Adobe if logging features are installed. They are, except Web-Custom-Logging that is not required from my perspective: Get-WindowsFeature Web-Health,Web-Http-Logging,Web-Custom-Logging,Web-Http-Tracing First level only waste my time...
Comment by Alexander H.
353 | October 04, 2017 02:59:17 PM GMT
I'd recommend referencing a previous case that I opened up earlier this year (6/26/17). My Case ID was 189033405. I was working with Abhishek. He was able to recreate the issue on his end but was unable to resolve the issue. Perhaps whoever you were working with could contact them?
Comment by Michael T.
354 | October 04, 2017 03:39:18 PM GMT
Ok, Abhishek is also managing my case. ID 189033405 is an internal support number, not the one here. If he cannot solve it personally, why has this not escalated to DEV?
Comment by Alexander H.
355 | October 04, 2017 03:58:53 PM GMT
Alexandar, I'll be honest with you. I do not believe Adobe is going to fix this issue. I have lost hope. I recognize that the next few sentences are out of context but in one of my email exchanges on the case with Abhishek, I said, "It FEELS like you are not taking responsibility for this issue and simply deferring to Microsoft." His disheartening response was, "We are certainly not running away with the problem. Had it been a CF issue, we would have fixed it for you. If you think this is a MS bug, then please reach out to them, to change their implementation/fix the bug. If you think this is a CF issue, feel free to log a bug at https://tracker.adobe.com/#/home . Our devs will look at it, accordingly. As far as the configuration guidance on IIS is concerned, you can continue to use the ones, you have from past. If any of those are not working expectedly, then please let us know and we will look at it. Lastly, you are correct that, Adobe has provided an installer for CF2016 on Windows 2016. And that works. We have control on our product, but if Microsoft has changed their implementation, then that’s outside Adobe ColdFusion’s scope of support." I have subsequently opened up threads with both Microsoft (https://forums.iis.net/t/1236914.aspx?ISAPI+and+IIS+10+Logging+Issues) and Tomcat (http://tomcat.10.x6.nabble.com/ISAPI-and-IIS-10-Logging-Issue-td5066963.html). From the Microsoft forum, it looks like they are recommending contacting the ISAPI author (Apache Tomcat). I contacted Apache and they recommend to contact Microsoft. So frustrating that I am the one having to try to resolve this for Adobe. Adobe needs to take charge of this issue and own it. Adobe needs to reach out to Microsoft AND Apache to coordinate a resolution. Clearly there is something wrong. Its not right or appropriate for an Adobe customer to have to go through such an order to fix an obvious and reproducible flaw in an Adobe product. I am all for community and forum collaboration but Adobe should be in the lead of this effort.
Comment by Michael T.
356 | October 04, 2017 04:22:36 PM GMT
@Michael: Thanks for the links. Customers cannot go to MS as MS only support their software. If you are the vendor of a software that has compatibility issues you can open a MS development case and they will help you resolving it. But you need to be the developer of the code and not just a user. You would otherwise just stay in the middle of a finger pointing scenario and I understand that this makes no sense to support and MS cannot fix the 3rd party software. The tomcat connector has been ***customized*** by Adobe, so they are 100% responsible for it. Once they find out the root cause they can fix it and give it back to tomcat team. They may point to timcat, but this is open source and I guess tomcat has no chance to open a developer case with MS. So Adobe need to call MS. I just had the same situation with our backup software on Windows 2016. It was a .NET 4.7 setup issue on the end of the day and our backup software vendor had managed all with MS. These .NET patches have been integrated into a windows rollup of mid August 2017 and later. Same can be done here if it is an MS issue. Without telling the vendor (e.g. MS) about the issue a patch cannot written.
Comment by Alexander H.
357 | October 09, 2017 02:13:41 PM GMT
Adobe, have you considered going the route of the HTTPPlatformHandler as Microsoft has suggested? Here are three great links for HTTPPlatformHandler: 1. Explaining HTTPPlatformHandler https://docs.microsoft.com/en-us/iis/extensions/httpplatformhandler/httpplatformhandler-configuration-reference 2. Configuring HTTPPlatformHandler with Tomcat https://blogs.msdn.microsoft.com/manjug/2015/11/27/understanding-iis-httpplatformhandler-using-tomcat-8/ 3. Download link to the HTTPPlatformHandler https://www.iis.net/downloads/microsoft/httpplatformhandler I haven't tested this out yet but will be spinning up a dev Win 2016 box in the near term to evaluate if the HTTPPlatformHandler is viable. Mark Thomas (ISAPI Author/Contributor) with Tomcat tested the ISAPI module on Win 2016 and has indicated that it may be a Microsoft bug in IIS 10 (http://tomcat.10.x6.nabble.com/ISAPI-and-IIS-10-Logging-Issue-td5066963.html). Adobe, can you please update this bug with a status? Are you looking at it? Contacting MS? Alexander, the system listed on this bug is Win 2012 Server x64. Did you have an option to select Windows 2016 when you logged it? Thanks.
Comment by Michael T.
358 | October 10, 2017 01:58:40 PM GMT
Hi, We are working on resolving this issue and have several findings: 1. IIS is wrongly logging the jakarta dll’s name which is registered to handle a certain type of extension, instead of logging the cs-stem-uri. 2. IIS has the handle to the logs that has the mentioned issue, not our connector or CF. 3. This issue is independent of the CF version or Connector version that is used. But reproducible with IIS10. it works fine with IIS8.5 4. Microsoft had faced this issues earlier also. We have reported this issue on Miscrosoft IIS Forum as well, where this issue is being tracked: https://forums.iis.net/p/1168716/2136576.aspx?Re+IIS+Advanced+Logging+issues+with+Tomcat+and+web+application
Comment by Nikhil S.
359 | October 11, 2017 07:18:46 AM GMT
I'm very interested to hear how this resolves. (I tried to just "vote" on the bug, on the right here, and it responded saying I could not vote on a bug I had created, but clearly Alexander created it, not me. Grr.) Oh well, it gives me a chance to note, for whatever it's worth, that someone in another forum thread discussing this (https://forums.iis.net/p/1236914/2135699.aspx?ISAPI+and+IIS+10+Logging+Issues) indicated just yesterday that they had found this was NOT happening on all IIS 10 servers they had, so it would seem there may be some configuration matter that could be influencing who sees the problem or not. Either way, it needs to be solved, whether by MS in IIS, or by Apache about the Tomcat IIS connector, or by Adobe about their modified Tomcat IIS connector. But since it is affecting other than just CF users, and seems to be an issue about IIS handling of such ISAPI requests, the solution may have to come from other than Adobe. We shall see.
Comment by Charlie A.
360 | October 12, 2017 04:23:26 AM GMT
@Nikhil Siddhartha: A forum is NOT a bugtracker, this is only a black hole. You need to open a support case with MS! What the heck are you waiting for? Call MS and work with them together to resolve the issue. You are the developers of the custom tomcat connector and you need to discuss this issue with MS development to move forward.
Comment by Alexander H.
361 | October 12, 2017 03:52:23 PM GMT
Quote: Did you have an option to select Windows 2016 when you logged it? No. Adobe bug tracker is not up to date.
Comment by Alexander H.
362 | October 12, 2017 04:16:43 PM GMT
Nikhil, I assume you saw the posting in the IIS thread (https://forums.iis.net/p/1168716/2136576.aspx?Re+IIS+Advanced+Logging+issues+with+Tomcat+and+web+application) by Paul Lynch who managed to get the logging working properly? According to his post, he is using Tomcat 8.5.23 and the 1.2.42 Connector. Any chance you can simulate this combination of versions in your environment to see if it resolves the issue? In my CF 16 with Update 5, it is using Tomcat 8.5.11 and using a connector with a version of 1.2.41.
Comment by Michael T.
363 | October 31, 2017 10:44:04 AM GMT
A fix has been discovered for this by jumiller in the IIS Forum (https://forums.iis.net/p/1168716/2137496.aspx?Re+IIS+Advanced+Logging+issues+with+Tomcat+and+web+application)!! Here is the excerpt: The c:\windows\system32\inetsrv\config\applicationHost.config file has a definition for IsapiFilter in the <location path="" overrideMode="Allow"><system.webServer><modules> section. The IsapiFilterModule needs to be before the HttpLoggingModule in the list. I've made this change on all of my Windows 2016 servers where logging wasn't working and they're all happy now, logging correctly.
Comment by Michael T.
364 | November 22, 2017 03:25:53 PM GMT
{color:#1f497d}Update: {color} {color:#1f497d}Microsoft has been investigating on this bug and have released the following public statement of the status of this bug: {color} {color:#1f497d}"When we are using Apache Tomcat Connector ( IIS ISAPI redirector plugin) with Windows Server 2016 / IIS 10 there is an issue currently where the  cs-uri-stem field is seen as “/Jakarta/isapi_redirect.dll” instead of the actual URI. This is currently being investigated. This does work in all previous versions of IIS."{color} {color:#1f497d}We are keeping a track of this issue and will update as soon as we hear something new on it.{color}
Comment by Nikhil S.
27550 | April 17, 2018 01:33:50 PM GMT
Per Abhishek Jha (Adobe) this bug has been fixed in Windows 2019 Build 17744.1001 and later. A fix for Windows 2016 is still unknown.
Comment by e
30665 | April 26, 2019 01:23:06 PM GMT