Broken URLs with Apache Tomcat
Posted: Thu Jun 01, 2017 5:50 am
I'm still struggling with Madcap Support on my issue with Web Help. I've identified the root cause and sent them more information on how to reproduce it. Its a somewhat specific scenario, but others might be encountering it. Here is what I believe to be the issue:
If your web help is hosted from an Apache Tomcat server, your pages may not load when the user selects links from the TOC. Apache Tomcat is a very popular web server for linux and Java based web applications. The problem is the way Madcap Flare 2017r2 is handling the pipe | symbol in the back-end javascript. The pipe symbols are used by Flare to pass query parameters to flare to correctly traverse the TOC. Pipe symbols as delimiters are optional, and most other special characters can be used. Pipe symbols need to be url encoded (%7C) when they are submitted to the tomcat server. In every version prior to 2017r2 the Flare javascript correctly encoded this.
To prove this, I took a flare generated hyperlink (that loads a broken page) and swapped the pipe symbol out for a plain text comma. Viola! The page loaded correctly. For example:
http://myaddress/default.htm#Jobs/index ... s%7C_____0 The pipe symbol appears to be URL encoded, but the page does not load and the Tomcat server reports and invalid character.
When I manually replace the url encoded pipe delimiter with a plain text comma, the page loads just fine.
http://myaddress/default.htm#Jobs/index ... ows,_____0
There are two options to fix this:
1) Madcap software determines how they've changed the way they handle the pipe delimiter and ensure it is url encoded when it gets submitted.
2) If you are on Apache Tomcat version 7.076, 8.0.42, or 8.5.12, you can request that your developers add the following property to Tomcat's catalina.properties file:
In our case, a developer set up a test instance of Tomcat, upgraded our server, (we are on a prior version of Tomcat) and applied the property. The webhelp now appears correctly in test. In order to implement a Tomcat upgrade into production will take extensive regression testing from out team, so we are holding out in hopes that Madcap will fix the issue they introduced in 2017r2. Otherwise we are not taking any Flare upgrades.
This issue will not present itself when launching the webhelp locally, or when the webhelp is hosted on an IIS server. Only when launched from the Apache Server. All the testing that Madcap has done to reproduce the issue has been from IIS servers, which has made it hard for them to reproduce the issue.
If your web help is hosted from an Apache Tomcat server, your pages may not load when the user selects links from the TOC. Apache Tomcat is a very popular web server for linux and Java based web applications. The problem is the way Madcap Flare 2017r2 is handling the pipe | symbol in the back-end javascript. The pipe symbols are used by Flare to pass query parameters to flare to correctly traverse the TOC. Pipe symbols as delimiters are optional, and most other special characters can be used. Pipe symbols need to be url encoded (%7C) when they are submitted to the tomcat server. In every version prior to 2017r2 the Flare javascript correctly encoded this.
To prove this, I took a flare generated hyperlink (that loads a broken page) and swapped the pipe symbol out for a plain text comma. Viola! The page loaded correctly. For example:
http://myaddress/default.htm#Jobs/index ... s%7C_____0 The pipe symbol appears to be URL encoded, but the page does not load and the Tomcat server reports and invalid character.
When I manually replace the url encoded pipe delimiter with a plain text comma, the page loads just fine.
http://myaddress/default.htm#Jobs/index ... ows,_____0
There are two options to fix this:
1) Madcap software determines how they've changed the way they handle the pipe delimiter and ensure it is url encoded when it gets submitted.
2) If you are on Apache Tomcat version 7.076, 8.0.42, or 8.5.12, you can request that your developers add the following property to Tomcat's catalina.properties file:
Code: Select all
tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}This issue will not present itself when launching the webhelp locally, or when the webhelp is hosted on an IIS server. Only when launched from the Apache Server. All the testing that Madcap has done to reproduce the issue has been from IIS servers, which has made it hard for them to reproduce the issue.