[jboss-jira] [Red Hat JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners

Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners --------------------------------------------------------------------------------------------------------- Key: WFLY-10929 URL: https://issues.redhat.com/browse/WFLY-10929 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 14.0.0.Beta2 Reporter: Jan Stourac Assignee: Bartosz Baranowski Priority: Major Labels: downstream_dependency Attachments: helloworld.war Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}. However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too. When HTTP request with unescaped characters is performed against server: {code} curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null {code} we get 200 OK HTTP response, although the result in access log looks like: {code:title=HTTP actual result} 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/í•œê¸€ì´ë¦ _test.html?param=í•œê¸€ì´ë¦ _ahoy HTTP/1.1" 200 950 {code} but we expect following: {code:title=HTTP expected result} 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950 {code} Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly: {code} curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure {code} we receive 404 Not Found HTTP response and following record in access.log: {code:HTTPS actual result} 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68 {code} however expected result should be similar to what we expect for HTTP, I guess.