I have a form like this.
<form id="hiddenForm" method="post" action="/my-controller/my-action/" enctype="multipart/form-data">
<input type="hidden" id="HiddenFormInput" name="HiddenFormInput">
</form>
which is produced by a web page accessible through https://[my-server]/my-controller/my-action/
, which is also the action the form points to.
On the server side, I differentiate between GET
and POST
requests. Either the page is shown plainly (GET
) or some results are shown depending on the form's values (POST
).
When I use jQuery to submit the form (I am NOT employing AJAX here, simply submitting the form), as in this snippet,
$("#hiddenForm").submit();
then jQuery seems to submit this form with GET
, although it's clearly marked to be submitted with POST
. Even an alert($("#hiddenForm").attr("method"));
always yields "post"
. However, this unwanted behaviour only occurs if the page has been loaded by a GET
. If the page came by a POST
, i.e. the form has already been submitted at least once, everything works just as expected.
Update
The problem was a plain old preventDefault()
one. The button that triggered the submit had a functionality of its own. It was a hyperlink. So I had this chain of actions.
- Hyperlink to
https://[my-server]/my-controller/my-action/#
- Submit form with action
https://[my-server]/my-controller/my-action/
.
Of course that would result in a GET
call without the form being submitted. Once I was on the page https://[my-server]/my-controller/my-action/#
the hyperlink lost it's functionality. That's why the second try always worked because the chain of actions was reduced to the submission of the form.
Hyperlink to(no effect because already there)https://[my-server]/my-controller/my-action/#
- Submit form with action
https://[my-server]/my-controller/my-action/
.
Then it worked of course.