As I understood when I analysed the behaviour of a POST request in a classic web application (by a form or an ajax request), the HttpServletRequest object must have both his content and parameters fields filled.
In HtmlUnitRequestBuilder.java, when converting the webRequest object into the MockHttpServletRequest the content field is filled only for an ajax request, and the parameters field are filled only for a form request. It seems there's a confusion about the meaning of the term parameters.
My correction is intended to have the parameters field filled for both the form and the ajax request when using an UI/UX unit test (as it is done when using a classic application).
Comment From: pivotal-cla
@jcaillabet Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
Comment From: bclozel
Is this related to #25768 ?
Comment From: jcaillabet
Hello
Yes, it is related to #25768. I work with guisimon28, and he suggested me to analyse the issue.
Comment From: pivotal-cla
@jcaillabet Thank you for signing the Contributor License Agreement!
Comment From: bclozel
I think we need to review the entire situation again. Especially if the intent on the HtmlUnit API is a bit clearer now. In the meantime I'm not sure this or really adresses all the situations (like array params and more).
Comment From: bclozel
I've just updated my repro project and the issue is still there.
I think we'll need to deal with the fact that WebRequest is an unreliable API and that we might need to parse the request body on the Spring Framework side. The problem with that approach is that since we have no understanding of the behavior and that this inconsistency won't be solved on the HtmlUnit side, we might run into more issues in the future.
I'll have a deeper look into your PR, but I can't guarantee a target milestone for now. For some reason, HtmlUnit/htmlunit#223 is still opened - so I'm wondering if a PR there would be safer - although I don't understand the link with the fetch API support in the last comment.
Comment From: thuri
I don't think the PR is a good solution. The code uses the requestBody property of the WebRequest, which may not have been filled by htmlunit (which actually is the main problem of HtmlUnit/hmlunit#223 ).
But regardless of that this PR would only work if the body is application/x-www-form-urlencoded and it would change the actual request as parameters that the client sends in the body are pushed to the URL when they are added to the WebRequest#setRequestParameters.
Spring (on the server side) will make params from the url and from the body available to the Controller methods via @RequestParam but that doesn't mean that we should change the request the client has made via htmlunit/mockmvc
Comment From: rstoyanchev
Indeed, @jcaillabet a key question missing from your analysis, is why does HtmlUnit behave in this way, i.e. exposing what looks like inconsistent behavior for Ajax vs regular form requests? And why should that be then addressed on the Spring side, and potentially duplicated in other places that use or build on HtmlUnit?
Comment From: jcaillabet
This is a good question that could be maybe aborded in HtmlUnit/htmlunit#223.
What I analysed is that HtmlUnit fill a WebRequest object differently if we do an ajax or a regular form request. For an ajax request the requestBody_ property is filled, and for a regular form request the requestParameters_ property will be filled. And the HtmlUnit javadoc explain that only one of then can be filled.
The problem I had is that in Spring we only read the requestParameters_ property, whatever the request type is. However I have tested a correction in HtmlUnit made by @thuri, that is correct for me. So finally I think that a correction in HtmlUnit is conceivable.
Comment From: bclozel
After reviewing this PR, I'm closing this for reasons explained in https://github.com/spring-projects/spring-framework/pull/27832#issuecomment-1003693721