-
Bug
-
Resolution: Done
-
Blocker
-
None
-
None
Reproducer is same as in the original issue JBEAP-13750 with JSP page:
<%@ page language="java" contentType="text/html; charset=MS949" pageEncoding="MS949" %>
<%
request.setCharacterEncoding("MS949");
out.print("param p=[" + request.getParameter("p") + "]");
%>
The current output is:
InvalidCharsRequestIT.allowKoreanCharsOverAjpTest:232->testAllowUnescapedKoreanChars:309
Expected: a string containing "param p=[한 글]"
but: was "HTTP/1.1 200 OK
Connection: close
X-Powered-By: JSP/3.1
Set-Cookie: JSESSIONID=A6uy_qh9h2-mBRsmKn11gxSmCN8Aje0dEJ537jA0.rhos-d-rhel8-medium-390; path=/invalid-chars
Content-Type: text/html;charset=MS949
Content-Length: 13
Date: Wed, 02 Oct 2024 08:15:42 GMT
param p=[\ �]"
This is a regression which can be observed with latest WildFly 34 builds (possibly from Beta1).
- is caused by
-
-
- Closed
-
- is cloned by
-
-
- Open
-
- relates to
-
-
- Closed
-
[JBEAP-28138] url-charset="MS949" does not work in AJP listener
Brian Stansberry
added a comment - istraka@redhat.com I've acked it. darran.lofthouse@redhat.com yes, we can hand over.
Yes, obsolete may be a good word for it NOW. I guess it was not obsolete in the creation time, but that is a history. IMHO, now it should be just verified. bstansbe@redhat.com are you able to ack this issue so we can proceed with verification? Verified with dev nack sounds odd.
Michal Petrov
added a comment - I can't ack. But there seems to be a bit of a mess - this issue is for 8.1, but we've got JBEAP-27975 for EAP 8.0 which looks like it was resolved completely independently of this one, although that one wasn't linked to WildFly. JBEAP-28046 is the component upgrade for 8.0, and I think all of this was done before 8.1 was created? So there's no component upgrade for 8.1 and this issue is technically duplicate/obsolete.
Michal Petrov
added a comment - I can't ack. But there seems to be a bit of a mess - this issue is for 8.1, but we've got JBEAP-27975 for EAP 8.0 which looks like it was resolved completely independently of this one, although that one wasn't linked to WildFly. JBEAP-28046 is the component upgrade for 8.0, and I think all of this was done before 8.1 was created? So there's no component upgrade for 8.1 and this issue is technically duplicate/obsolete. Thanks mpetrov@redhat.com. I reported WFLY-20442 so it is tracked. I expect component upgrade will resolve it.
Anyway, this was a regression and it is fixed now. @mpetrov@redhat.com can you ack this issue, link component upgrade jira (to 2.3.18.SP1) and move it to ready for QE? I think it can be verified then.
Michal Petrov
added a comment - istraka@redhat.com, it would appear UNDERTOW-2519 fixed it, that said the same test is in Undertow and it's still ignored - https://github.com/undertow-io/undertow/blob/85cb914965b24bcd3e3bd6075597ac1d031fa94e/core/src/test/java/io/undertow/server/protocol/ajp/AjpCharacterEncodingTestCase.java
Michal Petrov
added a comment - istraka@redhat.com , it would appear UNDERTOW-2519 fixed it, that said the same test is in Undertow and it's still ignored - https://github.com/undertow-io/undertow/blob/85cb914965b24bcd3e3bd6075597ac1d031fa94e/core/src/test/java/io/undertow/server/protocol/ajp/AjpCharacterEncodingTestCase.java Hi mpetrov@redhat.com, the test is here [1]
mvn clean verify -pl common,integration-tests -DnoTestNG -Djboss.home=`pwd`/jboss-eap-8.1 -Dit.test=InvalidCharsRequestIT#allowKoreanCharsOverAjpTest
It fails with WildFly 35.0.1, but it passes with EAP 8.1.0.Beta-CR6.2 [1]. Which is very strange. There is difference in artifacts:
$ find jboss-eap-8.1/ | grep undertow-core jboss-eap-8.1/modules/system/layers/base/io/undertow/core/main/undertow-core-2.3.18.SP1-redhat-00001.jar
vs
$ find wf35/ | grep undertow-core wf35/wildfly-35.0.1.Final/modules/system/layers/base/io/undertow/core/main/undertow-core-2.3.18.Final.jar
How come it is fixed? It should be either supported and test needs to pass or it is not supported and the test should fail.
cc flaviarnn rhn-cservice-bbaranow
[1] https://gitlab.cee.redhat.com/jbossqe-eap/tests-management/-/blob/master/integration-tests/src/test/java/org/jboss/qa/management/web/InvalidCharsRequestIT.java#L233
[2] https://eap-prod-share.usersys.redhat.com/eap/8.1.0.Beta-CR6.2-candidate/
Darran Lofthouse
added a comment - jkasik@redhat.com based on the discussions would you agree we can reject this JBEAP or do you require further discussion?
Darran Lofthouse
added a comment - jkasik@redhat.com based on the discussions would you agree we can reject this JBEAP or do you require further discussion? Michal Petrov
added a comment - darran.lofthouse@redhat.com, well, I don't have acking privileges. But also I tried asking Undertow and they don't seem to consider this a bug - https://wildfly.zulipchat.com/#narrow/channel/174183-undertow/topic/multibyte.20string.20encoding.20with.20AJP
Michal Petrov
added a comment - darran.lofthouse@redhat.com , well, I don't have acking privileges. But also I tried asking Undertow and they don't seem to consider this a bug - https://wildfly.zulipchat.com/#narrow/channel/174183-undertow/topic/multibyte.20string.20encoding.20with.20AJP Darran Lofthouse
added a comment - Hello mpetrov@redhat.com As this issue is assigned to you are you in a position to triage and dev ack if we agree this is a Blocker?
Darran Lofthouse
added a comment - Hello mpetrov@redhat.com As this issue is assigned to you are you in a position to triage and dev ack if we agree this is a Blocker? 
Verified with 8.1.0.Beta-CR9