On Fri, Apr 24, 2020 at 12:34 PM Igor Khvostenkov <igor.khvosten...@lindenbaum.eu.invalid> wrote:
> Hi Martin, > > Thanks for the hint with "Preserve log”. Looks like still this is exactly > what I described in reply to Sven. Browser does really POST request: > > > * > Request URL: > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > POST > * > Status Code: > 302 > * > Remote Address: > xxx:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./DHB1U_x9J1dRXqDe8wegYw/DHB6d > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > And then it gets redirect from proxy-server. And next request Browser > substitutes POST to GET, as stated in RFC: > > > * > Request URL: > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > GET > * > Status Code: > 302 > * > Remote Address: > 10.1.37.99:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./login.html?wicket-crypt=0SaMcpSjW2Y > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > Am I missing something? > I don't know. You tell us :-) Is there a problem with the functionality ? As far as I understood until now the problem was that there is no POST submit. Now you see that there is such. I hope you have some log statements in your Form#onSubmit() and #onError() and you can verify either of those is called. > > -Igor. > > On 24. Apr 2020, at 09:41, Martin Grigorov <mgrigo...@apache.org<mailto: > mgrigo...@apache.org>> wrote: > > On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov > <igor.khvosten...@lindenbaum.eu.invalid<mailto: > igor.khvosten...@lindenbaum.eu.invalid>> wrote: > > 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. > > > Yes, you should see POST with status 302 and then GET. > But to see them both you need to check "Preserve log" in the Network tab. > Otherwise the browser shows only the requests for the last load of the page > (including the request for the page itself and all resources like > css/js/images) > > > > -Igor. > > On 24. Apr 2020, at 06:02, Martin Grigorov <mgrigo...@apache.org<mailto: > mgrigo...@apache.org><mailto: > 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><mailto: > 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>><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> > > > > > > > >
