Hi Martin, Yes, this is login form with special “token".
If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov <mgrigo...@apache.org<mailto:mgrigo...@apache.org>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov <igor.khvosten...@lindenbaum.eu.invalid<mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier <s...@meiers.net<mailto:s...@meiers.net><mailto: s...@meiers.net<mailto:s...@meiers.net>>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98. Starting from Wicket 7.16 you distinguish between GET and POST in FormComponent#getInputAsArray() and for the form submit this will not work in case of redirect. -Igor. On 23. Apr 2020, at 17:15, Sven Meier <s...@meiers.net<mailto:s...@meiers.net><mailto: s...@meiers.net<mailto:s...@meiers.net>><mailto:s...@meiers.net>> wrote: Hi, if the generated HTML contains method="post", the browser will send the form as post request. Without more detailed information, it's hard to find the error. Can you write a quickstart? Have fun Sven On 23.04.20 11:59, Igor Khvostenkov wrote: Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: <pre> <form role="form" id="accessForm5" wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm" method="post" action="./login.html;jsessionid=8B3813A1300187D10FE8211AF47D9F7F?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm" wicketsource="Login.java:39"><div style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden" class="hidden-fields"><input type="hidden" name="accessForm5_hf_0" id="accessForm5_hf_0"></div> <wicket:container id="feedback6" style="display:none"></wicket:container> <h2>Konferenz-Teilnehmer</h2> <div class="form-group"> <div class="input-group"> <input id=“code" type="text" class="form-control" value="" name=“code" wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_code" placeholder=“Code" wicketsource="LoginForm.java:50"> <span class="input-group-btn"> <input id="login" type="submit" class="btn btn-primary" wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_wicket__message__attr__6578556" value="Teilnehmen"> </span> </div> </div> </form> </pre Request Headers: 1. :authority: xxx 2. :method: GET 3. :path: /conference/ng/login.html?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm Is that a login form that you try to submit ? Or it is another form and the server sees that you are not authenticated and this is the reason to redirect you to login.html ? Another explanation for the misterious GET could be that Wicket uses RedirectAfterPost pattern to prevent double submits. See https://en.wikipedia.org/wiki/Post/Redirect/Get for more details. 4. :scheme: https 5. accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 6. accept-encoding: gzip, deflate, br 7. accept-language: de 8. cookie: JSESSIONID=8B3813A1300187D10FE8211AF47D9F7F 9. referer: https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org<mailto: users-unsubscr...@wicket.apache.org> For additional commands, e-mail: users-h...@wicket.apache.org<mailto: users-h...@wicket.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org<mailto: users-unsubscr...@wicket.apache.org> For additional commands, e-mail: users-h...@wicket.apache.org<mailto: users-h...@wicket.apache.org>
