Tomcat 7.0.82 enforces uriEncoding, the SDK does not

[tom-vandepoele]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request

Expected Behavior

The (embedded) tomcat version run by the SDK is configurable, so SDK tomcat can match the tomcat version of a production server.

Current Behavior

When running the SDK tomcat version 7.0.47 is used. This cannot be changed currently.

Possible Solution

See http://tomcat.apache.org/maven-plugin-2.2/tomcat7-maven-plugin/adjust-embedded-tomcat-version.html
By exposing the tomcat version to the alfresco maven plugin configuration.

Context

In Alfresco 5.2.3 a breaking change is introduced with tomcat 7.0.82 which most developers will not be aware of until they deploy their application on an actual server.

Namely, HTTP request validation is changed so certain special characters are no longer allowed and instead of returning a usable error, the server will on any of these 'invalid' uris just simply return 400 bad request with no further info.

Should developers not have had the discipline to properly encode their URIs with encodeURIComponent, their applications, while working just fine running on the SDK will break in a normal server environment.

By allowing the SDK to specify the tomcat runtime, these problems can be caught earlier in the development stage.

Your Environment

• Alfresco SDK version used: 3.0.1
• Alfresco version used: 5.2.3

Additional information

This is the message the catalina.out will show when hitting an invalid uri in tomcat 7.0.82:

INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
at org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:238)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1028)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2555)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2544)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

[tom-vandepoele]

Note a workaround (which exposes the tomcat server security-wise, but is a valid alternative to downgrading tomcat) is to re-enable this line in the catalina.properties on the production server:

# Allow for changes to HTTP request validation
# WARNING: Using this option will expose the server to CVE-2016-6816
#tomcat.util.http.parser.HttpParser.requestTargetAllow=|

The only real solution is to properly encode all request URIs (REST calls), of course.

[ohej]

Pull request #521 addresses this so the Tomcat version can be updated. Will be included in SDK 3.1.