https redirect failed for POST request when behind a load balancer
Hi, I've been looking for a solution to this question. We have a setup of a couple api servers running tomcat 7.0.65. For both servers we had http redirect to https set up so when people access to http://my-api1:8080, it is automatically redirect to https://my-api1:8443 The redirect works fine for all our REST services. However, when we setup a load balancer in front of the two servers, and setup the redirect as following: http://api-lb:8080 to https://lb-api:8443, our POST was redirected as GET causing the request to fail. Is there any setup we can do to force the POST not being redirect to GET? Many Thanks, Bin
RE: https redirect failed for POST request when behind a load balancer
Konstantin: Thank you very much for your reply. To answer your question 1. The api-lb and lb-api was a typo. 2. I was able to reproduce this problem with a single server behind the load balancer. Where http://lb-test-api:8080 was set to forward to https://lb-test-api:8443 using vip. On the test server, 8080 was redirect to 8443 in server.xml and modified web.xml as described in tomcat doc. My war file's web.xml also included section. With these settings, my Post request to http://my-test-api:8080 was automatically redirect to https://my-test-api:8443 with no problem. The Post is a REST webservice call so single response was received. Inside the access log, when post via the load balancer 10.166.27.33 - - [19/Jan/2017:11:21:27 -0800] 8443 "GET /theacturalapicallurl HTTP/1.1" 405 1045 When post directly to the my-test-api:8080, the access log got recorded as 10.20.96.62 - - [19/Jan/2017:11:28:15 -0800] 8080 "POST /theacturalapicallur HTTP1.1l" 201 277 3. Here is my setup (load balancer) (my-test-api) This looks to me like Tomcat is performing the POST Redirect GET when there is a proxy and the call was redirected to prevent the server from MITM attack. Hopefully this clarifies my question, Thank you very much, Bin -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Wednesday, January 18, 2017 11:43 PM To: Tomcat Users List Subject: Re: https redirect failed for POST request when behind a load balancer 1. You know that "api-lb" and "lb-api" above are two different host names? 2. What HTTP response code is send to client to perform the redirection? (What is displayed by access log? Or by "network" monitoring tool in browser. What are actual responses to perform the redirection). Some response codes used for redirects allow the browser to change POST to GET, some do not. See the HTTP protocol specification for details. https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_tomcat_Specifications&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ&m=g9XvhdAG4g80Ajw7i4CvF3kysWtESxDF6NFX8j630c8&s=mOjl8_uOfuo3lfn8xDS6jwCZao9az7SjXLxgAh-2Twc&e= Is redirect performed by a single response, or there are several redirect responses in a chain, A -> B -> C/ ? 3. Actual configuration? (For someone else to reproduce the issue or to match your tale to their configs). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: https redirect failed for POST request when behind a load balancer
Peter: Our Load balancer uses a VIP to do the redirect, so when a request coming in as http://lb-api:8080, it changes it into https://lb-api:8443 and submit to the api server behind. I could not see any redirect logged into the access log. However, if I submit a request to the api server directly using http://my-api:8080, I'd see a redirect return code of 302 and another entry after that with the request to port 8443. Almost make me thing it might be the load balancer that is redirecting the POST request to a GET. Is that possible? Thank you again, Bin -Original Message- From: Kreuser, Peter [mailto:pkreu...@airplus.com] Sent: Friday, January 20, 2017 1:43 AM To: Tomcat Users List Subject: AW: https redirect failed for POST request when behind a load balancer Hi Bin I wonder if the redirect will use a 301 or 302 and that per default results in a GET. How is this implemented in the loadbalancer? As I read a 307 should preserve the request method. From: https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_13628831_apache-2D301-2Dredirect-2Dand-2Dpreserving-2Dpost-2Ddata&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ&m=quLXN4mLB8a4NNSXBq_y8iftNygJUC3ZqeL5gYH46So&s=Cr-WfGYAinyNBtKqFUGgzoXRehN9Mfw-Ssq2Q24Hpvk&e= If you want to enforce the redirect to https, you should however consider a different approach. If it is necessary to protect the data, no POST should ever go to http/port 8080, as the data will be open in the first request. So in my opinion the calling website/application that is sending the data to 8080 should be modified in the first place. Best regards Peter > -Original Message- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: Wednesday, January 18, 2017 11:43 PM > To: Tomcat Users List > Subject: Re: https redirect failed for POST request when behind a load > balancer > > 1. You know that "api-lb" and "lb-api" above are two different host names? > > 2. What HTTP response code is send to client to perform the redirection? > (What is displayed by access log? Or by "network" monitoring tool in browser. > What are actual responses to perform the redirection). > > Some response codes used for redirects allow the browser to change POST to > GET, some do not. See the HTTP protocol specification for details. > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_tomcat_Specifications&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ&m=g9XvhdAG4g80Ajw7i4CvF3kysWtESxDF6NFX8j630c8&s=mOjl8_uOfuo3lfn8xDS6jwCZao9az7SjXLxgAh-2Twc&e= > > > Is redirect performed by a single response, or there are several redirect > responses in a chain, A -> B -> C/ ? > > 3. Actual configuration? > > (For someone else to reproduce the issue or to match your tale to their > configs). > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: https redirect failed for POST request when behind a load balancer
Peter: To answer your questions 1. The response header when using 8080 to post, I got: Status Code: 405 Method Not Allowed Allow: POST Cache-Control: private Content-Language: en Content-Length: 1045 Content-Type: text/html;charset=utf-8 Date: Mon, 23 Jan 2017 18:48:07 GMT Expires: Wed, 31 Dec 1969 16:00:00 PST Server: Apache-Coyote/1.1 This agrees to the access log record When using 8443 for the same POST operation, I got: Status Code: 201 Created Content-Length: 277 Content-Type: application/xml Date: Mon, 23 Jan 2017 18:51:25 GMT Server: Apache-Coyote/1.1 Which also agrees to the access log record. For your second question: I understand the risk and consequence of using redirect for POST, this is just an alternative for us for a short period of time, we will force all our users to move the https before we can shut down the 8080 for POST. We are working on that in the meantime. Thank you very much, Bin -Original Message- The redirect takes place in the client. What kind of client do you use? Could you send us the response headers from the two setups? You did not answer on my recommendation to fix the app to be https from the start. In that case the redirect will be unnecessary... Peter
RE: https redirect failed for POST request when behind a load balancer
Peter: Here is what I got when using curl on a client. curl -I http://lb-api:8080/urls?param1=something\¶m2=123 HTTP/1.0 302 Found Location: https://lb-api:8443/ urls?param1=something\¶m2=123 Server: BigIP Connection: Keep-Alive Content-Length: 0 Our engineer who has access to the load balancer is off today, will get some log info on the load balancer side about the redirect. Thank you, Bin -Original Message- From: Kreuser, Peter [mailto:pkreu...@airplus.com] Sent: Tuesday, January 24, 2017 7:06 AM To: Tomcat Users List Subject: AW: https redirect failed for POST request when behind a load balancer These are the responses to the redirected calls. But the redirect to https is happening before... Something like: curl -I https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mysite.com&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ&m=s9vxUp8T2qmtXcpTf24_22u9yokdaI0KB86CHPf6Eww&s=h-Vox3nBr8QIbljS45du0NmHAfIlQh6G_lmOdT4wuek&e= HTTP/1.0 301 Moved Permanently Location: https:// www.mysite.com Server: Apache Connection: Keep-Alive Content-Length: 0 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: https redirect failed for POST request when behind a load balancer
Peter: Checked F5 and found that it was the proper behavior of F5 in this http to https redirect. There is a way to use iRule to change that. Thank you very much! Bin -Original Message- From: Kreuser, Peter [mailto:pkreu...@airplus.com] Sent: Wednesday, January 25, 2017 1:22 AM To: Tomcat Users List Subject: AW: https redirect failed for POST request when behind a load balancer Bin, So it is working as designed in the RFC... https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_HTTP-5F302&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ&m=Cd24gJffDyonEJHgpKqwRRHfhBVcnuh3ZXbrUn1wq6w&s=O-RpRIWcNXyjocbL9uVgxk9VkouVffRloYNsr1Jq7xM&e= -> 302 leads to a resend with GET. If your client would speak HTTP/1.1, a 307 response code could be interpreted as preserving the request type as originally sent. It may be feasible to send this RC in a BigIP iRule for this specific URL. But it is still depending on the client implementation. And I have not seen this in the wild. Now: how does the client get to the POST with http? If your app runs in a regular browser and uses relative URLs, upgrade the first request to https (probably a GET), then after that all links, forms will be on https. Best regards Peter
