Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Problem is not in the application but in the configuration put proxy which does the redirect in front of the any application with form submit. IMHO this change https://issues.apache.org/jira/browse/WICKET-6708 does not keep in mind that it could be redirect call with GET request with POST parameters. -Igor. On 24. Apr 2020, at 20:57, Martin Grigorov mailto:mgrigo...@apache.org>> wrote: Please create a demo application so we can take a look! On Fri, Apr 24, 2020 at 9:31 PM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Sven, Same stuff with crypto off. Here is with debugger on getParameterValues: -Igor. On 24. Apr 2020, at 18:51, Sven Meier mailto:s...@meiers.net>> wrote: Hi, Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw Request Method: GET that is a GET request with query parameters. Form inputs should be able to pick up the values from the query parameters. Maybe the problem is related to the cryptoMapper? Could you disable it for a test? Have fun Sven On 24.04.20 17:43, Igor Khvostenkov wrote: Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net mailto:s...@meiers.net>>>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov 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? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto: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 mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>><mailto: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 mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@l
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Sven, Same stuff with crypto off. Here is with debugger on getParameterValues: [cid:D2B48B44-E9C2-4E26-A9B4-C807FE5E8E00@lbaum.eu] -Igor. On 24. Apr 2020, at 18:51, Sven Meier mailto:s...@meiers.net>> wrote: Hi, >Request URL: >https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw >Request Method: >GET that is a GET request with query parameters. Form inputs should be able to pick up the values from the query parameters. Maybe the problem is related to the cryptoMapper? Could you disable it for a test? Have fun Sven On 24.04.20 17:43, Igor Khvostenkov wrote: Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net><mailto:s...@meiers.net>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov 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? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto: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 mailto: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 mailto: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 mailto:s...@meiers.net><mailto:s...@meiers.net>mailto:s...@meiers.net><mailto:s...@meiers.net>>mailto:s...@meiers.net><
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov 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? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto: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 mailto: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 mailto: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 mailto: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
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
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? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov 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 mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov 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 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 mailto:s...@meiers.net>><mailto:s...@meiers.net&
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
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 mailto:mgrigo...@apache.org>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov 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 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 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: Konferenz-Teilnehmer 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 For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
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 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 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: Konferenz-Teilnehmer 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>
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
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 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: Konferenz-Teilnehmer 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>
Form submit sends GET request, if Wicket-generated URL contains jsessionId
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: Konferenz-Teilnehmer 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.
Re: Is there an example project for wicket-spring-boot with gradle and webpack?
Sorry, replied the wrong mail =( -Igor. > On 11. Dec 2019, at 10:44, Igor Khvostenkov > wrote: > > https://teleconf.lab2018.qa.lbaum.eu/conference/x/xS--GWk72BL0 > >> On 8. Dec 2019, at 20:24, Martin Grigorov wrote: >> >> Hi, >> >> I would suggest you to generate your application with JHipster and then >> remove the front-end (Angular/React) and add Wicket instead. >> >> On Sun, Dec 8, 2019, 10:02 Per Newgro wrote: >> >>> Hello *, >>> >>> i try to setup a spring boot project based on wicket-spring-boot-parent. >>> To built my frontend assets (sass, js, svg minify etc) i like to use >>> webpack. >>> >>> But if i start my project the assets are not loaded. So i hope to find an >>> example project, >>> where i can find some inspirations how i could setup everything. >>> >>> Btw. i built everything with gradle. >>> >>> Thanks for your support >>> Per >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is there an example project for wicket-spring-boot with gradle and webpack?
https://teleconf.lab2018.qa.lbaum.eu/conference/x/xS--GWk72BL0 > On 8. Dec 2019, at 20:24, Martin Grigorov wrote: > > Hi, > > I would suggest you to generate your application with JHipster and then > remove the front-end (Angular/React) and add Wicket instead. > > On Sun, Dec 8, 2019, 10:02 Per Newgro wrote: > >> Hello *, >> >> i try to setup a spring boot project based on wicket-spring-boot-parent. >> To built my frontend assets (sass, js, svg minify etc) i like to use >> webpack. >> >> But if i start my project the assets are not loaded. So i hope to find an >> example project, >> where i can find some inspirations how i could setup everything. >> >> Btw. i built everything with gradle. >> >> Thanks for your support >> Per >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
