Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-15994

[GSS](7.2.z) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Major
    • None
    • None
    • Undertow
    • None
    • +
    • Hide
      1. unzip WildFly and start via ./bin/standalone.sh
      2. in CLI perform following operations: 
        /subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
 /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=use-server-log, value=false)

deploy helloworld.war
reload
      3. Now try to access WildFly server: 
        # First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log

# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
      Show
      unzip WildFly and start via ./bin/standalone.sh in CLI perform following operations: /subsystem=undertow/server= default -server/host= default -host/setting=access-log:add() /subsystem=undertow/server= default -server/http-listener= default :write-attribute(name=allow-unescaped-characters-in-url,value= true ) /subsystem=undertow/server= default -server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value= true ) /subsystem=undertow/server= default -server/host= default -host/setting=access-log:write-attribute(name=use-server-log, value= false ) deploy helloworld.war reload Now try to access WildFly server: # First against HTTP listener: curl "http: //localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/ null # Check result in access log # Now try against HTTPS listener: curl "https: //localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/ null --insecure # Check result in access log

    Description

      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:

      curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null

      we get 200 OK HTTP response, although the result in access log looks like:

      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

      but we expect following:

      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

      Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly:

      curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure

      we receive 404 Not Found HTTP response and following record in access.log:

      Unable to find source-code formatter for language: https actual result. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
      127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68

      however expected result should be similar to what we expect for HTTP, I guess.

      Attachments

        1. helloworld.war
          4 kB
        2. patch.patch
          14 kB

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-18627 [GSS](7.3.z) WFLY-10929 - Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is caused by

          Bug - A problem that impairs or prevents the functions of the product. UNDERTOW-2312 multibytes language in URL request to http/https are broken in EAP access log.

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Pull Request Sent
          is related to

          Bug - A problem that impairs or prevents the functions of the product. UNDERTOW-1185 Undertow does not allow UTF-8 characters in URLs

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Bug - A problem that impairs or prevents the functions of the product. UNDERTOW-1385 url-charset="UTF-8" didn't work in ajp-listener

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Bug - A problem that impairs or prevents the functions of the product. UNDERTOW-1386 multibytes language in URL request to ajp-listener are broken in EAP access log.

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Bug - A problem that impairs or prevents the functions of the product. UNDERTOW-1399 multibytes language in URL query part of request to ajp-listener is broken

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              rhn-cservice-bbaranow Bartosz Baranowski
              rhn-support-bmaxwell Brad Maxwell
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: