[ALF-21851] Tomcat 7.0.73, 8.0.39, 8.5.7 - starting from these version throws error on illegal characters Created: 10-Feb-17  Updated: 19-Jun-17  Resolved: 09-Mar-17

Status: Closed
Project: Alfresco
Component/s: Installer, Share Application
Affects Version/s: Community Edition 201701 GA
Fix Version/s: Community Edition 201704 GA
Security Level: external (External user)

Type: Bug Priority: Major
Reporter: Peter Löfgren Assignee: Closed Issues
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tomcat 7.0.73, 8.0.39, 8.5.7 or newer

Issue Links:
Depended on by ACE-5222 Upgrade from Tomcat 7 to Tomcat 8 for... Closed
duplicates MNT-17415 When editing properties of a content ... Closed
is duplicated by ALF-21878 Newer Tomcat versions use stricter im... Closed
relates to MNT-16664 Encoding/decoding URL issue with Tomc... Closed
is related to by REPO-1465 Upgrade from Tomcat 7 Done
Date of First Response:
Resolution Time Custom Field: 3 weeks, 6 days, 8 hours, 26 minutes, 50 seconds


Starting from Tomcat 7.0.73, 8.0.39, 8.5.7 there is a stricter handling of illegal characters.
From Tomcat change log
" Add additional checks for valid characters to the HTTP request line parsing so invalid request lines are rejected sooner. (markt)"

While this is not an Alfresco issue it exposes bugs present in Alfresco.
One such issue is is in file share/src/main/webapp/components/documentlibrary/actions.js
line 347

         var templateUrl = YAHOO.lang.substitute(Alfresco.constants.URL_SERVICECONTEXT + "components/form?itemKind={itemKind}&itemId={itemId}&destination={destination}&mode={mode}&submitType={submitType}&formId={formId}&showCancelButton=true",
            itemKind: "node",
            itemId: nodeRef,
            mode: "edit",
            submitType: "json",
            formId: "doclib-simple-metadata"

Here the the destination parameter is never set, and this results in a request with a parameter destination=


that has the illegal characters{}

This one can easily be fixed of course, but there may be other cases like this. Maybe the YAHOO.lang.substitute should be patched to remove any remaining {}-characters just to be safe (but this maybe cause other bugs).

The above-mentioned issue is the only one I have found so far, but there may be other as testing continues.

As for now, the solution is to stay off any version of tomcat with the mentioned versions or newer, in the long term it is a good thing as it exposes bad code.

I listed a version affected but this applies to any version of Alfresco that use a newer version of tomcat.

Comment by Douglas Cassiano Rodrigues Paes [ 13-Feb-17 ]

I am facing the same problem here and I am going to downgrade the Tomcat's version.

Yes, the downgrade worked.
I am using the 8.0.38 version now and everything seems to be ok.

Comment by Richard Esplin [X] (Inactive) [ 16-Feb-17 ]

This sounds like MNT-16664, but it has a different root cause.

Comment by Richard Esplin [X] (Inactive) [ 16-Feb-17 ]

Thank you for reporting this issue Peter Löfgren. We will pay attention to this as we look to upgrade the version of Tomcat that we officially support.

Comment by Kevin Roast [X] (Inactive) [ 09-Mar-17 ]

This has already been fixed on the 5.N service pack branch and will be merged to HEAD in due course. Thanks for raising it.

Comment by Kevin Roast [X] (Inactive) [ 09-Mar-17 ]

FYI this NOT related to MNT-16664

Comment by Kevin Roast [X] (Inactive) [ 13-Mar-17 ]

Merged r135798. Should be in next nightly build and next Community build.

Comment by Jérémie Lesage (Inactive) [ 16-May-17 ]

A workaround is available since Tomcat 7.0.76, 8.0.42, 8.5.12 using property tomcat.util.http.parser.HttpParser.requestTargetAllow


Generated at Sat Jul 11 05:24:17 BST 2020 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.