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.