[Red Hat JIRA] (DROOLS-5938) In accumulate implemention of executable model field binding overtake pattern binding even when not appropiate
by Mario Fusco (Jira)
Mario Fusco created DROOLS-5938:
-----------------------------------
Summary: In accumulate implemention of executable model field binding overtake pattern binding even when not appropiate
Key: DROOLS-5938
URL: https://issues.redhat.com/browse/DROOLS-5938
Project: Drools
Issue Type: Bug
Components: executable model
Reporter: Mario Fusco
Assignee: Mario Fusco
When translated into the executable model the following rule works correctly
{code:java}
global java.util.List result;
rule R when
$acc1 : Collection() from accumulate(
$p : Person( ), collectSet( $p ) )
then
result.add($acc1.iterator().next());
end{code}
but if a field binding is added to the accumulated pattern like in
{code:java}
global java.util.List result;
rule R when
$acc1 : Collection() from accumulate(
$p : Person( $name : name ), collectSet( $p ) )
then
result.add($acc1.iterator().next());
end {code}
then the accumulation is wrongly performed on the bound field, the person's name in this case, instead of on the Person object itself as specified in the accumulating function.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5897) Compound BigDecimal operator is translated to assignOperator in MVEL
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5897?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi reassigned DROOLS-5897:
-----------------------------------------
Assignee: Toshiya Kobayashi (was: Luca Molteni)
> Compound BigDecimal operator is translated to assignOperator in MVEL
> --------------------------------------------------------------------
>
> Key: DROOLS-5897
> URL: https://issues.redhat.com/browse/DROOLS-5897
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Luca Molteni
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> {code:java}
> @Test
> @Ignore("without B it doesn't work on MVEL")
> public void testCompoundOperator() throws Exception {
> // DROOLS-5894
> String drl =
> "import " + Person.class.getCanonicalName() + "\n" +
> "dialect \"mvel\"\n" +
> "rule R\n" +
> "when\n" +
> " $p : Person( age >= 26 )\n" +
> "then\n" +
> " $p.money += 50000;\n" +
> "end";
> KieSession ksession = getKieSession(drl);
> Person john = new Person("John", 30);
> john.setMoney( new BigDecimal( 70000 ) );
> ksession.insert(john);
> assertEquals(1, ksession.fireAllRules());
> assertEquals(new BigDecimal( 120000 ), john.getMoney());
> }{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5937) Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5937?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5937:
--------------------------------------
Story Points: 4
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5937
> URL: https://issues.redhat.com/browse/DROOLS-5937
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.48.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
> Attachments: reproducer_02801729_6_mvel.zip, reproducer_02801729_6e_6f.zip
>
>
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL (org.mvel2).
> When using MVEL.eval method, the result of "+=" operation is incorrect, and "-=", "*=", "/=" operations result in an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 1000 // incorrect result
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 1000 // incorrect result
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> When using MVEL.executeExpression method, the result of "+=" operation is correct, while "-=", "*=", "/=" operations cause an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 13000 // correct
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 13000 // correct
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> $bus.weight is a BigDecimal type property.
> MVEL library should return correct result for any operations above.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5937) Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5937?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi moved RHDM-1558 to DROOLS-5937:
-------------------------------------------------
Component/s: core engine
(was: BRE)
Docs QE Status: NEW
Key: DROOLS-5937 (was: RHDM-1558)
QE Status: NEW
Affects Version/s: 7.48.0.Final
(was: 7.9.0.GA)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Environment: (was: The issue was found in RHDM 7.9.0.)
Project: Drools (was: Red Hat Decision Manager)
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL.
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5937
> URL: https://issues.redhat.com/browse/DROOLS-5937
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.48.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
> Attachments: reproducer_02801729_6_mvel.zip, reproducer_02801729_6e_6f.zip
>
>
> Compound assignment operation like BigDecimal_type_property <op> Numeric/BigDecimal_value causes an unexpected result or error in MVEL (org.mvel2).
> When using MVEL.eval method, the result of "+=" operation is incorrect, and "-=", "*=", "/=" operations result in an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 1000 // incorrect result
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 1000 // incorrect result
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> When using MVEL.executeExpression method, the result of "+=" operation is correct, while "-=", "*=", "/=" operations cause an error.
> - BigDecimal_type_property <op> Numeric_value (Initial value of $bus.weight is 12000B)
> -- $bus.weight += 1000 ==> 13000 // correct
> -- $bus.weight -= 1000 ==> Error
> -- $bus.weight *= 1000 ==> Error
> -- $bus.weight /= 1000 ==> Error
> - BigDecimal_type_property <op> BigDecimal_value (Initial value of $bus.weight and bdv are 12000B and 1000B respectively)
> -- $bus.weight += bdv ==> 13000 // correct
> -- $bus.weight -= bdv ==> Error
> -- $bus.weight *= bdv ==> Error
> -- $bus.weight /= bdv ==> Error
> $bus.weight is a BigDecimal type property.
> MVEL library should return correct result for any operations above.
--
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 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:
---------------------------------
Description:
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}
Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all, doesn't get logged by {{io.undertow.request.dump}} either.
The error I get on DEBUG level:
{code:java}
2021-01-08 01:32:20,660 DEBUG [io.undertow.request.io] (default I/O-7) Sending rststream on channel Http2Channel peer /127.0.0.1:50355 local /127.0.0.1:443[ No Receiver [] -- [] -- []] stream 1: java.nio.channels.ClosedChannelException
at io.undertow.core@2.2.2.Final//io.undertow.protocols.http2.Http2Channel.sendRstStream(Http2Channel.java:1059)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleRequests(Http2ReceiveListener.java:135)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:115)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:73)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:952)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener$1.run(AbstractFramedChannel.java:963)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:939)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.8.2.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:180)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$2.run(SslConduit.java:195)
at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479){code}
was:
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}
Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all.
The error I get on DEBUG level:
{code:java}
2021-01-08 01:32:20,660 DEBUG [io.undertow.request.io] (default I/O-7) Sending rststream on channel Http2Channel peer /127.0.0.1:50355 local /127.0.0.1:443[ No Receiver [] -- [] -- []] stream 1: java.nio.channels.ClosedChannelException
at io.undertow.core@2.2.2.Final//io.undertow.protocols.http2.Http2Channel.sendRstStream(Http2Channel.java:1059)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleRequests(Http2ReceiveListener.java:135)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:115)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:73)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:952)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener$1.run(AbstractFramedChannel.java:963)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:939)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.8.2.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:180)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$2.run(SslConduit.java:195)
at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479){code}
> 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
> Attachments: server log (trace).txt
>
>
> 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}
>
> Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all, doesn't get logged by {{io.undertow.request.dump}} either.
> The error I get on DEBUG level:
> {code:java}
> 2021-01-08 01:32:20,660 DEBUG [io.undertow.request.io] (default I/O-7) Sending rststream on channel Http2Channel peer /127.0.0.1:50355 local /127.0.0.1:443[ No Receiver [] -- [] -- []] stream 1: java.nio.channels.ClosedChannelException
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.http2.Http2Channel.sendRstStream(Http2Channel.java:1059)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleRequests(Http2ReceiveListener.java:135)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:115)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:73)
> at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:952)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
> at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener$1.run(AbstractFramedChannel.java:963)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:939)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
> at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.8.2.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:180)
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$2.run(SslConduit.java:195)
> at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479){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 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:
---------------------------------
Description:
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}
Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all.
The error I get on DEBUG level:
{code:java}
2021-01-08 01:32:20,660 DEBUG [io.undertow.request.io] (default I/O-7) Sending rststream on channel Http2Channel peer /127.0.0.1:50355 local /127.0.0.1:443[ No Receiver [] -- [] -- []] stream 1: java.nio.channels.ClosedChannelException
at io.undertow.core@2.2.2.Final//io.undertow.protocols.http2.Http2Channel.sendRstStream(Http2Channel.java:1059)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleRequests(Http2ReceiveListener.java:135)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:115)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:73)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:952)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener$1.run(AbstractFramedChannel.java:963)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:939)
at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.8.2.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:180)
at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$2.run(SslConduit.java:195)
at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479){code}
was:
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}
Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all.
> 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
> Attachments: server log (trace).txt
>
>
> 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}
>
> Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all.
> The error I get on DEBUG level:
> {code:java}
> 2021-01-08 01:32:20,660 DEBUG [io.undertow.request.io] (default I/O-7) Sending rststream on channel Http2Channel peer /127.0.0.1:50355 local /127.0.0.1:443[ No Receiver [] -- [] -- []] stream 1: java.nio.channels.ClosedChannelException
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.http2.Http2Channel.sendRstStream(Http2Channel.java:1059)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleRequests(Http2ReceiveListener.java:135)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:115)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:73)
> at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:952)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
> at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener$1.run(AbstractFramedChannel.java:963)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:939)
> at io.undertow.core@2.2.2.Final//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
> at org.jboss.xnio@3.8.2.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.8.2.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:180)
> at io.undertow.core@2.2.2.Final//io.undertow.protocols.ssl.SslConduit$2.run(SslConduit.java:195)
> at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.jboss.xnio.nio@3.8.2.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479){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 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:
---------------------------------
Description:
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}
Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all.
was:
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}
> 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
> Attachments: server log (trace).txt
>
>
> 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}
>
> Server log excerpt with TRACE level logging attached. The faulty request is */rest/v3/news/_lite* - it can be seen in one of the TRACE logs with | (pipe) symbol in its query string, but then it doesn't get "deeper", doesn't get processed at all.
--
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 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:
---------------------------------
Attachment: server log (trace).txt
> 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
> Attachments: server log (trace).txt
>
>
> 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] (WFCORE-5240) Add a ManagementResourceRegistration.registerSubModelIfAbsent method
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5240?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-5240:
------------------------------------------
I think the use case needs a bit more of a think.
In the datasource and resource-adapter subsystem use cases, a putIfAbsent semantic may not be correct. The semantic is only correct if the provided ResourceDefinition is equivalent to the one the resulted in the existing MRR. And that may not be the case; e.g. in the r-a case (and I think datasources too) the ResourceDefinition details depend on what stats are provided by a particular rar. But the registration is, for example, against
{code}
/subsystem=resource-adapters/resource-adapter=*/connection-definition=foo
{code}
You can have services from two RAs that use competely different rars with very different statistics both invoking that. That should not work.
For that to be safe, the registration would need to be against a concrete resource-adapter address, not the wildcard:
{code}
/subsystem=resource-adapters/resource-adapter=bar/connection-definition=foo
{code}
But if that was the address, multiple calls is likely a bug, and a putIfAbsent semantic (even the broken one currently used) would be wrong.
> Add a ManagementResourceRegistration.registerSubModelIfAbsent method
> --------------------------------------------------------------------
>
> Key: WFCORE-5240
> URL: https://issues.redhat.com/browse/WFCORE-5240
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> Subsystems, particularly datasources and resource-adapters, have code like this that's called from service start methods:
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or...
> This is basically trying for a quasi putIfAbsent semantic. But it's not really reliable, particularly if multiple services are doing the same thing during boot.
> So, add a proper putIfAbsent-type submodel registration method to ManagementResourceRegistration.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months