Broken URLs with Apache Tomcat

This forum is for all Flare issues not related to any of the other categories.
Post Reply
ChrisBradley
Propeller Head
Posts: 55
Joined: Thu Dec 13, 2007 12:24 pm

Broken URLs with Apache Tomcat

Post by ChrisBradley »

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:

Code: Select all

tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
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.
Madcap Advanced Developer
BedfordWriter
Sr. Propeller Head
Posts: 217
Joined: Wed Jun 23, 2010 10:13 am
Location: Nova Scotia

Re: 2017r2 - update or not?

Post by BedfordWriter »

Only now catching up with the forums and this thread in particular. I've been using r2, blithly unaware of its troubles. (Ignoring any that I bumped into as they didn't seem to have a significant impact on what I've been doing recently.)

I installed 6355 a couple of weeks ago. So far as I can tell, it seems to be working just fine. (Actually, this is an edited post. I thought I had found a new bug but it turned out to be an error on my part. I'd have deleted this post altogether, but I can't see how to do anything other than edit it.)
lil
Jr. Propeller Head
Posts: 4
Joined: Tue Aug 18, 2015 2:38 pm

Re: 2017r2 - update or not?

Post by lil »

Chris,

Everytime Flare sends an update or new version, the 'junk' reappears in the URL. You can prevent it from happening by commenting out a line in the MadcapAll.js file found in the following folder:

C:\Program Files\MadCap Software\MadCap Flare V13\Flare.app\Resources\WebHelp2\Desktop\Scripts

I'm currently on version 13.2.6334.20174
In my text editor, the line of code to comment out is in line 57 (text wrapping turned off).
It gets longer and more complicated each time, but I eventually find it and it works:

if(L!=null&&Q&&P){var V=y(Y,true);if(MadCap.Utilities.HasRuntimeFileType("TriPane")){L+=encodeURIComponent("?"+Q+"Path="+V)}else{var M=new MadCap.Utilities.Url(L);L=M.PlainPath+"?"+(Q+"Path="+V)+M.Fragment}}

HTH!
Psider
Propellus Maximus
Posts: 811
Joined: Wed Jul 06, 2011 1:32 am

Re: 2017r2 - update or not?

Post by Psider »

I found this about the ugly vs clean URL in the latest help - not sure it helps, but thought I'd post for people to check out:
http://help.madcapsoftware.com/flare201 ... =toc%20url
NorthEast
Master Propellus Maximus
Posts: 6359
Joined: Mon Mar 05, 2007 8:33 am

Re: Broken URLs with Apache Tomcat

Post by NorthEast »

Chris - I split these posts from the other thread as it seems to be a useful topic by itself, and is more likely to be found by others if it's in its own thread.
lil wrote:Everytime Flare sends an update or new version, the 'junk' reappears in the URL. You can prevent it from happening by commenting out a line in the MadcapAll.js file found in the following folder:
If you do this, will it break how TOC sync now works in 2017r2? (if you select the option mentioned by Psider above)
ChrisBradley
Propeller Head
Posts: 55
Joined: Thu Dec 13, 2007 12:24 pm

Re: Broken URLs with Apache Tomcat

Post by ChrisBradley »

Thanks Dave.

I got a followup from Madcap Support. They were able to reproduce this issue on an Apache Tomcat server and verified it was introduced in 2017r2. Their temporary solution was to downgrade to the previous version of Flare.

I previously reported that users can add a property to the catalina.properties file to accept the pipe symbol. I have to caution you however as that method can expose the server to a potential cross-site scripting attack that is documented in CVE-2016-6816.

The best solution is for Flare to fix the issue.
Madcap Advanced Developer
ChrisBradley
Propeller Head
Posts: 55
Joined: Thu Dec 13, 2007 12:24 pm

Re: 2017r2 - update or not?

Post by ChrisBradley »

Psider wrote:I found this about the ugly vs clean URL in the latest help - not sure it helps, but thought I'd post for people to check out:
http://help.madcapsoftware.com/flare201 ... =toc%20url
This was helpful for understanding how the url is created. I use the option to sync my TOC and I would not want to give it up if I can help it.
Madcap Advanced Developer
jralst_20
Jr. Propeller Head
Posts: 2
Joined: Mon Jul 13, 2015 4:21 pm

Re: Broken URLs with Apache Tomcat

Post by jralst_20 »

This issue has just come up for me, but I am not on 2017r2; I'm still on 11.1.2. Pages go blank in Chrome 59. It's fine in earlier versions of our product, but I suspect the upcoming version where it's broken must use a newer Tomcat version.
amygil
Propeller Head
Posts: 11
Joined: Tue Dec 06, 2011 4:38 pm

Re: Broken URLs with Apache Tomcat

Post by amygil »

Does anybody know when we can expect a fix for this?
ChrisBradley
Propeller Head
Posts: 55
Joined: Thu Dec 13, 2007 12:24 pm

Re: Broken URLs with Apache Tomcat

Post by ChrisBradley »

amygil wrote:Does anybody know when we can expect a fix for this?
I have not recieved any updates from my case (I seldom do until a fix is released).
Madcap Advanced Developer
ckretz
Jr. Propeller Head
Posts: 1
Joined: Thu May 18, 2017 4:54 am

Re: Broken URLs with Apache Tomcat

Post by ckretz »

According to web standards, characters like | should be URL-encoded (%7C in this case).

Starting in 7.0.73, Tomcat started enforcing the relevant web standard and
now rejects URLs with all kinds of technically illegal characters. This was in
response to a particular web security concern, CVE-2016-6816
(https://nvd.nist.gov/vuln/detail/CVE-2016-6816), which could arise when using
Tomcat behind certain kinds of web proxies.
ChrisBradley
Propeller Head
Posts: 55
Joined: Thu Dec 13, 2007 12:24 pm

Re: Broken URLs with Apache Tomcat

Post by ChrisBradley »

ckretz wrote:According to web standards, characters like | should be URL-encoded (%7C in this case).

Starting in 7.0.73, Tomcat started enforcing the relevant web standard and
now rejects URLs with all kinds of technically illegal characters. This was in
response to a particular web security concern, CVE-2016-6816
(https://nvd.nist.gov/vuln/detail/CVE-2016-6816), which could arise when using
Tomcat behind certain kinds of web proxies.
Right. And the issue is that Madcap is not correctly encoding that character when help is launched using CSHIDs. We are still waiting on Madcap to fix the issue.
Madcap Advanced Developer
ChrisBradley
Propeller Head
Posts: 55
Joined: Thu Dec 13, 2007 12:24 pm

Re: Broken URLs with Apache Tomcat

Post by ChrisBradley »

Looks like Madcap released Flare 2017 r3 today. The release notes indicate this issue has been fixed.
http://kb.madcapsoftware.com/Content/Fl ... _Notes.htm
Issue 130870

I have tested this on my apache server, and I no longer have the issue where the pages will not load correctly. Thanks Madcap!
Madcap Advanced Developer
rmehta
Jr. Propeller Head
Posts: 1
Joined: Tue May 30, 2017 8:54 am

Re: Broken URLs with Apache Tomcat

Post by rmehta »

Dropped by just to check if the issue was fixed yet, not disappointed. Thanks!
ChrisBradley wrote:Looks like Madcap released Flare 2017 r3 today. The release notes indicate this issue has been fixed.
http://kb.madcapsoftware.com/Content/Fl ... _Notes.htm
Issue 130870
SoleWriter
Propeller Head
Posts: 42
Joined: Thu Nov 27, 2014 7:44 am
Location: United Kingdom

Re: Broken URLs with Apache Tomcat

Post by SoleWriter »

Has anyone encountered this issue with Flare 2019 r2?

We seem to be having this issue with the newest version of Flare.

Any thoughts would be greatly appreciated. Thanks!
TeSol
Sr. Propeller Head
Posts: 114
Joined: Wed Sep 14, 2011 12:02 am

Re: Broken URLs with Apache Tomcat

Post by TeSol »

Came across this email thread while browsing the forum looking for a solution to broken urls with Apache tomcat. I'm using Flare 2019 r2 Side Navigation output and facing this issue while using Previous and Next in the Topic Toolbar as well as in Search Results. When I test the help as a standalone there is no issue. But once it is integrated with the application, the page crashes.

My target Advanced tab has 'Synchronize Navigation elements with TOC entries' checked - though I don't know if that is a cause.

Any help in this regard is greatly appreciated as my release deadline is just 10 days away.
Post Reply