I have a problem with https redirect from call initiated in the backend. I have a Nginx Ingress Controller with the following setup:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-sample
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
rules:
- http:
paths:
- path: /
backend:
serviceName: sample
servicePort: 8080It works fine when client access the page through the browser - it uses https to contact with a load balancer and the traffic from the load balancer to pods in the cluster uses HTTP (so SSL is terminated at LB level and a client is forced to use HTTPS). However, when I try to call from my Java application the URL which uses HTTP (like a client is doing) I expect to be redirected automatically to the HTTPS. I receive the correct response (308 permanent redirect) but my call is not automatically moved to https. Is some annotation missing?
no, I'm not a java expert, but I suppose your java app doesnt follow redirects (since you are getting 308 permanent redirect) especially since you confirmed this works in the browser. Try something like this:
https://www.mkyong.com/java/java-httpurlconnection-follow-redirect-example/
URLConnection Doesn't Follow Redirect
In my Java application, I was using Apache Http Client version 4.5.5. This client uses DefaultRedirectStrategy class which handles redirection. I checked the implementation and in this version it does not handle code 308 (does not redirect). Because I did not want to change anything in the application code I found out that it is possible to change redirect code which is used by Nginx. It can be achieved via ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
labels:
app: nginx-ingress
chart: nginx-ingress-0.17.1
component: "controller"
heritage: Tiller
release: sample-nginx
name: sample-ingress-controller
data:
http-redirect-code: "301"Apache Http Client in version 4.5.5 follows redirects with 301 response code so now everything works fine. Recently there was also a commit to the Apache Http Client repo which handles 308 response code the same way as 301.