|
Hi guys again continue with this http 500 processing,
After reviewing in more detail with my team we decided to create a challenge to this. Basically we thought that it is not the ideal behavior that the htmlunit framework is changing the 500 status code from the server to a new exception:com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException
And also, to not hack the server side async calls to always return 200 status code in case of error
For now, we saw that if from the TCK side the following option is set to false then all the failing tests will pass:
webClient.getOptions().setThrowExceptionOnFailingStatusCode(false)
let me know if any question
From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> on behalf of arjan tijms <arjan.tijms@xxxxxxxxx>
Sent: Monday, June 6, 2022 12:25 PM
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Subject: Re: [cdi-dev] HTTP 500 error incompatible processing
On Mon, Jun 6, 2022 at 6:54 PM Alfonso Altamirano <alfonso.altamirano@xxxxxxxxxxx> wrote:
Basically Do you mean that to pass those tests should I need to not return the 500 error automatically from server and for now how this is an async implementation leave it with a success code?
is this correct?
Yes, that seems to be "correct", in the way that this is what we're seemingly all doing. Like with a bunch of tests it's a question why these fail now and not with the previous version of the TCK. This one too is not a new test I think. Something must
have changed somewhere, but for the moment I can't figure out what.
Kind regards,
Arjan Tijms
Hi,
Thanks Mark, for now I’ll keep the behaviour then as-is in Piranha. Maybe good indeed to see what can be clarified for Servlet.next.
Kind regards,
Arjan Tijms
On Monday, June 6, 2022, Mark Thomas < markt@xxxxxxxxxx> wrote:
Hi,
This is one of those areas where there is still a need for further clarity in the specification. I don't recall (and can't find) anything that would disagree with your assessment.
Mark
On 06/06/2022 13:02, arjan tijms wrote:
Hi,
I implemented Servlet in Piranha, though I’m not sure if that makes me a true expert. My understanding at least (which may be wrong), is that when an exception is thrown in async code, the onError handler is responsible for setting a 500 or not.
So I opted, like WildFly, not to have a 500 automatically send by the container. I did had my doubts here too, and there’s no test in the Servlet TCK asserting this.
Maybe Mark or Greg can comment here? (Servlet list cc’ed)
Kind regards,
Arjan Tijms
On Monday, June 6, 2022, Matej Novotny <manovotn@xxxxxxxxxx <mailto:manovotn@xxxxxxxxxx>> wrote:
Helo,
this is a good question.
I took a look at
ApplicationContextAsyncListenerTest.testApplicationContextActiveOnError
and run it on WFLY.
To my own surprise, the return code I saw there during debug was 200.
I am no servlet expert so someone else might jump in and explain how
this is supposed to work.
The servlet in question (AsyncServlet) doesn't throw any exception
itself so theoretically it returns successfully while the async
processing and delegation continues.
It delegates to an instance of `ExecutorService` and uses
`SimpleAsyncListener` to monitor the result. From within the
listener, I can correctly detect the "onError" method being triggered.
I am going to try to look into servlet spec to get a hang of what
should be returned in this case.
Either we have the test wrong (but both, WFLY and Liberty pass,
supposedly also GF) or some of the server behaviors are wrong.
If someone knows more, feel free to jump in and correct my
assumptions :)
Matej
On Sat, Jun 4, 2022 at 3:05 AM Alfonso Altamirano
<alfonso.altamirano@xxxxxxxxxxx> wrote:
Hi guys,
Again with something related to the CDI-TCK execution. I'm using
the version 4.0.1 and when executing I'm seeing the following error:
[mvn.test]
com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException:
500 Internal Server Error for
http://localhost:8080/ApplicationContextAsyncListenerTestf171a3d3289dcf8237159d936219ff9c87d85db/AsyncServlet?test=error
<http://localhost:8080/ApplicationContextAsyncListenerTestf171a3d3289dcf8237159d936219ff9c87d85db/AsyncServlet?test=error>
The source of this issue came from the following tests:
* org.jboss.cdi.tck.tests.context.application.async.ApplicationContextAsyncListenerTest.testApplicationContextActiveOnError
* org.jboss.cdi.tck.tests.context.conversation.determination.ConversationDeterminationTest.testConversationDetermination
* org.jboss.cdi.tck.tests.context.request.async.RequestContextAsyncListenerTest.testRequestContextActiveOnError
* org.jboss.cdi.tck.tests.context.session.async.SessionContextAsyncListenerTest.testSessionContextActiveOnError
I'm not sure if this is correct because when checking details of
the test I saw that the Servlet called is going to generate a
ServletException that is going to cause an error 500 from the
Server, but the following block of code from the htmlunit
implementation make me think that I need to configure something
to disable the throw of the FailingHttpStatusCodeException. Do
you know how to pass this exception? or Do you know what to
config to pass this tests?
this is the block of code from the htmlunit implementation:
WebClient:
public void throwFailingHttpStatusCodeExceptionIfNecessary(WebResponse webResponse) {
int statusCode = webResponse.getStatusCode();
boolean successful = statusCode >=200 && statusCode <300 || statusCode ==305 || statusCode ==304;
if (this.getOptions().isThrowExceptionOnFailingStatusCode() && !successful) {
throw new FailingHttpStatusCodeException(webResponse);
}
}
regards
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx <mailto:cdi-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdi-dev
<https://www.eclipse.org/mailman/listinfo/cdi-dev>
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdi-dev
|
