[Red Hat JIRA] (WFLY-14269) Wildfly 21's “allow-unescaped-characters-in-url” ignored when HTTP2 request going through Windows hosts file
by Marton Csukas (Jira)
[ https://issues.redhat.com/browse/WFLY-14269?page=com.atlassian.jira.plugi... ]
Marton Csukas updated WFLY-14269:
---------------------------------
Summary: Wildfly 21's “allow-unescaped-characters-in-url” ignored when HTTP2 request going through Windows hosts file (was: Wildfly 21's “allow-unescaped-characters-in-url” ignored when request going through Windows hosts file)
> Wildfly 21's “allow-unescaped-characters-in-url” ignored when HTTP2 request going through Windows hosts file
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14269
> URL: https://issues.redhat.com/browse/WFLY-14269
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 21.0.0.Final, 21.0.1.Final, 21.0.2.Final
> Reporter: Marton Csukas
> Assignee: Flavia Rainone
> Priority: Major
>
> I have a _Wildfly 21.0.0.Final_ running a Spring Boot REST application and I encountered a strange behaviour with {{GET}} requests containing {{|}} (pipe) character in the query parameters.
> {{|}} (pipe) character is unsafe according to the RFC1738 specification of HTTP, while RFC3986 allows for the encoding of Unicode characters.
> However, Wildfly (Undertow) has an option on {{http-listener}} and {{https-listener}} entries to {{allow-unescaped-characters-in-url}}.
> Full {{standalone.xml}} [here|https://gist.github.com/martoncsukas/746695... masked sensitive info.
>
> The application is running on {{127.0.0.1:443}}, and is exposed to the outside world as [https://myappname.company.com|https://myappname.company.com/] via a PulseSecure load balancer, where {{myappname}} is a CNAME registered on {{company.com}} DNS, pointing to the load balancers VIP.
> The {{allow-unescaped-characters-in-url="true"}} bit works fine in these cases (so when the request containing {{|}} _doesn't_ go through the Windows {{hosts}} file, but goes through the load balancer).
> However, when I add an entry to the Windows {{hosts}} file to bypass the load balancer, such as:
> 127.0.0.1 myappname.company.com
> …then the {{GET}} request containing {{|}} in its query parameter won't work - in fact it looks like it is not even hitting the server, as if Wildfly/Undertow's {{allow-unescaped-characters-in-url="true"}} setting wouldn't even be there.
> Now this causes issues with our local testing. Is there any change we can make so that {{allow-unescaped-characters-in-url="true"}} would be always respected?
> We know that ideally {{|}} should be encoded to {{%7D}}, but we would be interested in a solution (ideally on Wildfly level) that would make {{allow-unescaped-characters-in-url="true"}} work every time, irrespective whether the requests is going through {{hosts}} file or the load balancer.
> The very strange this is that it was working fine in _Wildfly 20.0.0.Final_, even without {{allow-unescaped-characters-in-url="true"}} being in {{standalone.xml}}.
>
> Full request source:
> {code:java}
> GET /rest/v3/news/_lite?mql=customerId=1212090,caseId=1078841||caseId=null
> HTTP/1.1
> Host: myappname.company.com
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-cache
> sec-ch-ua: "Google Chrome";v="87", " Not;A Brand";v="99", "Chromium";v="87"
> Accept: application/json, text/plain, */*
> Authorization: Bearer masked
> sec-ch-ua-mobile: ?0
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
> Sec-Fetch-Site: same-origin
> Sec-Fetch-Mode: cors
> Sec-Fetch-Dest: empty
> Referer: https://myappname.company.com/anotherPage
> Accept-Encoding: gzip, deflate, br
> Accept-Language: en-GB,en;q=0.9
> Cookie: JSESSIONID=masked; _ga=GA1.2.1926489359.1609961117; _gid=masked; _gat_gtag_UA_112487518_3=1{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14269) Wildfly 21's “allow-unescaped-characters-in-url” ignored when request going through Windows hosts file
by Marton Csukas (Jira)
[ https://issues.redhat.com/browse/WFLY-14269?page=com.atlassian.jira.plugi... ]
Marton Csukas updated WFLY-14269:
---------------------------------
Summary: Wildfly 21's “allow-unescaped-characters-in-url” ignored when request going through Windows hosts file (was: allow-unescaped-characters-in-url="true")
> Wildfly 21's “allow-unescaped-characters-in-url” ignored when request going through Windows hosts file
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14269
> URL: https://issues.redhat.com/browse/WFLY-14269
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 21.0.0.Final, 21.0.1.Final, 21.0.2.Final
> Reporter: Marton Csukas
> Assignee: Flavia Rainone
> Priority: Major
>
> I have a _Wildfly 21.0.0.Final_ running a Spring Boot REST application and I encountered a strange behaviour with {{GET}} requests containing {{|}} (pipe) character in the query parameters.
> {{|}} (pipe) character is unsafe according to the RFC1738 specification of HTTP, while RFC3986 allows for the encoding of Unicode characters.
> However, Wildfly (Undertow) has an option on {{http-listener}} and {{https-listener}} entries to {{allow-unescaped-characters-in-url}}.
> Full {{standalone.xml}} [here|https://gist.github.com/martoncsukas/746695... masked sensitive info.
>
> The application is running on {{127.0.0.1:443}}, and is exposed to the outside world as [https://myappname.company.com|https://myappname.company.com/] via a PulseSecure load balancer, where {{myappname}} is a CNAME registered on {{company.com}} DNS, pointing to the load balancers VIP.
> The {{allow-unescaped-characters-in-url="true"}} bit works fine in these cases (so when the request containing {{|}} _doesn't_ go through the Windows {{hosts}} file, but goes through the load balancer).
> However, when I add an entry to the Windows {{hosts}} file to bypass the load balancer, such as:
> 127.0.0.1 myappname.company.com
> …then the {{GET}} request containing {{|}} in its query parameter won't work - in fact it looks like it is not even hitting the server, as if Wildfly/Undertow's {{allow-unescaped-characters-in-url="true"}} setting wouldn't even be there.
> Now this causes issues with our local testing. Is there any change we can make so that {{allow-unescaped-characters-in-url="true"}} would be always respected?
> We know that ideally {{|}} should be encoded to {{%7D}}, but we would be interested in a solution (ideally on Wildfly level) that would make {{allow-unescaped-characters-in-url="true"}} work every time, irrespective whether the requests is going through {{hosts}} file or the load balancer.
> The very strange this is that it was working fine in _Wildfly 20.0.0.Final_, even without {{allow-unescaped-characters-in-url="true"}} being in {{standalone.xml}}.
>
> Full request source:
> {code:java}
> GET /rest/v3/news/_lite?mql=customerId=1212090,caseId=1078841||caseId=null
> HTTP/1.1
> Host: myappname.company.com
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-cache
> sec-ch-ua: "Google Chrome";v="87", " Not;A Brand";v="99", "Chromium";v="87"
> Accept: application/json, text/plain, */*
> Authorization: Bearer masked
> sec-ch-ua-mobile: ?0
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
> Sec-Fetch-Site: same-origin
> Sec-Fetch-Mode: cors
> Sec-Fetch-Dest: empty
> Referer: https://myappname.company.com/anotherPage
> Accept-Encoding: gzip, deflate, br
> Accept-Language: en-GB,en;q=0.9
> Cookie: JSESSIONID=masked; _ga=GA1.2.1926489359.1609961117; _gid=masked; _gat_gtag_UA_112487518_3=1{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14269) allow-unescaped-characters-in-url="true"
by Marton Csukas (Jira)
[ https://issues.redhat.com/browse/WFLY-14269?page=com.atlassian.jira.plugi... ]
Marton Csukas updated WFLY-14269:
---------------------------------
Steps to Reproduce:
* Have an entry in your Windows hosts file for the endpoint you are about to test, e.g.:
{code:java}
127.0.0.1 myappname.company.com{code}
* On _Wildfly 21.0.0.Final_ send a GET request with at least one | (pipe) character in the query parameters
* In latest Chrome (Version 87.0.4280.88 (Official Build) (64-bit)) or Firefox call a GET request with unencoded | (pipe) symbol in the query (e.g.: GET myappname.company.com/myAPI?someParam=customerId=1212090,caseId=1078841||...)
* On Wildfly 21.0.× this will result in a ERR_HTTP2_PROTOCOL_ERROR, and a 4×× error code - with the request not even hitting the application
* On Wildfly 20.0.× this works fine, as expected.
If you remove the entry from the hosts file though, and the request goes through the company load balancer for myappname.company.com, the request will be successful.
was:
* Have an entry in your Windows hosts file for the endpoint you are about to test, e.g.:
**
127.0.0.1 myappname.company.com
* On _Wildfly 21.0.0.Final_ send a GET request with at least one | (pipe) character in the query parameters
* In latest Chrome (Version 87.0.4280.88 (Official Build) (64-bit)) or Firefox call a GET request with unencoded | (pipe) symbol in the query (e.g.: GET myappname.company.com/myAPI?someParam=customerId=1212090,caseId=1078841||...)
* On Wildfly 21.0.× this will result in a ERR_HTTP2_PROTOCOL_ERROR, and a 4×× error code - with the request not even hitting the application
* On Wildfly 20.0.× this works fine, as expected.
> allow-unescaped-characters-in-url="true"
> ----------------------------------------
>
> Key: WFLY-14269
> URL: https://issues.redhat.com/browse/WFLY-14269
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 21.0.0.Final, 21.0.1.Final, 21.0.2.Final
> Reporter: Marton Csukas
> Assignee: Flavia Rainone
> Priority: Major
>
> I have a _Wildfly 21.0.0.Final_ running a Spring Boot REST application and I encountered a strange behaviour with {{GET}} requests containing {{|}} (pipe) character in the query parameters.
> {{|}} (pipe) character is unsafe according to the RFC1738 specification of HTTP, while RFC3986 allows for the encoding of Unicode characters.
> However, Wildfly (Undertow) has an option on {{http-listener}} and {{https-listener}} entries to {{allow-unescaped-characters-in-url}}.
> Full {{standalone.xml}} [here|https://gist.github.com/martoncsukas/746695... masked sensitive info.
>
> The application is running on {{127.0.0.1:443}}, and is exposed to the outside world as [https://myappname.company.com|https://myappname.company.com/] via a PulseSecure load balancer, where {{myappname}} is a CNAME registered on {{company.com}} DNS, pointing to the load balancers VIP.
> The {{allow-unescaped-characters-in-url="true"}} bit works fine in these cases (so when the request containing {{|}} _doesn't_ go through the Windows {{hosts}} file, but goes through the load balancer).
> However, when I add an entry to the Windows {{hosts}} file to bypass the load balancer, such as:
> 127.0.0.1 myappname.company.com
> …then the {{GET}} request containing {{|}} in its query parameter won't work - in fact it looks like it is not even hitting the server, as if Wildfly/Undertow's {{allow-unescaped-characters-in-url="true"}} setting wouldn't even be there.
> Now this causes issues with our local testing. Is there any change we can make so that {{allow-unescaped-characters-in-url="true"}} would be always respected?
> We know that ideally {{|}} should be encoded to {{%7D}}, but we would be interested in a solution (ideally on Wildfly level) that would make {{allow-unescaped-characters-in-url="true"}} work every time, irrespective whether the requests is going through {{hosts}} file or the load balancer.
> The very strange this is that it was working fine in _Wildfly 20.0.0.Final_, even without {{allow-unescaped-characters-in-url="true"}} being in {{standalone.xml}}.
>
> Full request source:
> {code:java}
> GET /rest/v3/news/_lite?mql=customerId=1212090,caseId=1078841||caseId=null
> HTTP/1.1
> Host: myappname.company.com
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-cache
> sec-ch-ua: "Google Chrome";v="87", " Not;A Brand";v="99", "Chromium";v="87"
> Accept: application/json, text/plain, */*
> Authorization: Bearer masked
> sec-ch-ua-mobile: ?0
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
> Sec-Fetch-Site: same-origin
> Sec-Fetch-Mode: cors
> Sec-Fetch-Dest: empty
> Referer: https://myappname.company.com/anotherPage
> Accept-Encoding: gzip, deflate, br
> Accept-Language: en-GB,en;q=0.9
> Cookie: JSESSIONID=masked; _ga=GA1.2.1926489359.1609961117; _gid=masked; _gat_gtag_UA_112487518_3=1{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14269) allow-unescaped-characters-in-url="true"
by Marton Csukas (Jira)
Marton Csukas created WFLY-14269:
------------------------------------
Summary: allow-unescaped-characters-in-url="true"
Key: WFLY-14269
URL: https://issues.redhat.com/browse/WFLY-14269
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 21.0.2.Final, 21.0.1.Final, 21.0.0.Final
Reporter: Marton Csukas
Assignee: Flavia Rainone
I have a _Wildfly 21.0.0.Final_ running a Spring Boot REST application and I encountered a strange behaviour with {{GET}} requests containing {{|}} (pipe) character in the query parameters.
{{|}} (pipe) character is unsafe according to the RFC1738 specification of HTTP, while RFC3986 allows for the encoding of Unicode characters.
However, Wildfly (Undertow) has an option on {{http-listener}} and {{https-listener}} entries to {{allow-unescaped-characters-in-url}}.
Full {{standalone.xml}} [here|https://gist.github.com/martoncsukas/746695... masked sensitive info.
The application is running on {{127.0.0.1:443}}, and is exposed to the outside world as [https://myappname.company.com|https://myappname.company.com/] via a PulseSecure load balancer, where {{myappname}} is a CNAME registered on {{company.com}} DNS, pointing to the load balancers VIP.
The {{allow-unescaped-characters-in-url="true"}} bit works fine in these cases (so when the request containing {{|}} _doesn't_ go through the Windows {{hosts}} file, but goes through the load balancer).
However, when I add an entry to the Windows {{hosts}} file to bypass the load balancer, such as:
127.0.0.1 myappname.company.com
…then the {{GET}} request containing {{|}} in its query parameter won't work - in fact it looks like it is not even hitting the server, as if Wildfly/Undertow's {{allow-unescaped-characters-in-url="true"}} setting wouldn't even be there.
Now this causes issues with our local testing. Is there any change we can make so that {{allow-unescaped-characters-in-url="true"}} would be always respected?
We know that ideally {{|}} should be encoded to {{%7D}}, but we would be interested in a solution (ideally on Wildfly level) that would make {{allow-unescaped-characters-in-url="true"}} work every time, irrespective whether the requests is going through {{hosts}} file or the load balancer.
The very strange this is that it was working fine in _Wildfly 20.0.0.Final_, even without {{allow-unescaped-characters-in-url="true"}} being in {{standalone.xml}}.
Full request source:
{code:java}
GET /rest/v3/news/_lite?mql=customerId=1212090,caseId=1078841||caseId=null
HTTP/1.1
Host: myappname.company.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
sec-ch-ua: "Google Chrome";v="87", " Not;A Brand";v="99", "Chromium";v="87"
Accept: application/json, text/plain, */*
Authorization: Bearer masked
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://myappname.company.com/anotherPage
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en;q=0.9
Cookie: JSESSIONID=masked; _ga=GA1.2.1926489359.1609961117; _gid=masked; _gat_gtag_UA_112487518_3=1{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months