Getting http in the Location-header when the original request was made over https
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
My questions:
1) Why do I get http as the scheme in the Location-header when the original request from the browser was made with https?
2) Is this an wildfly load balancer problem?
My Request Header is:
method: POST
scheme: https
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
content-length: 39
content-type: application/x-www-form-urlencoded
origin: https://10.43.201.207
referer: https://10.43.201.207/myapp/login.html
My Response Header is:
content-length: 0
date: Thu, 03 Jan 2019 04:55:42 GMT
location: http://10.43.201.207/myapp/dashboard.html?init=1
server: WildFly/12
set-cookie: APP_AUTH=leTPWYd1222zsrrtRRtgpuEWEWc7pR0CBuNPYPT5QHbGn_Db7ICK; path=/; secure; HttpOnly
set-cookie: JSESSIONID="leTee33333PWYdSDSDweetRRtgpuc7pR0CBuNPYPT5QHbGn_Db7ICK.master-0:master-server"; Version=1; Path=/myapp; Secure; HttpOnly
status: 302
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: Undertow/1
x-xss-protection: 1; mode=block
http ssl redirect https undertow
add a comment |
My questions:
1) Why do I get http as the scheme in the Location-header when the original request from the browser was made with https?
2) Is this an wildfly load balancer problem?
My Request Header is:
method: POST
scheme: https
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
content-length: 39
content-type: application/x-www-form-urlencoded
origin: https://10.43.201.207
referer: https://10.43.201.207/myapp/login.html
My Response Header is:
content-length: 0
date: Thu, 03 Jan 2019 04:55:42 GMT
location: http://10.43.201.207/myapp/dashboard.html?init=1
server: WildFly/12
set-cookie: APP_AUTH=leTPWYd1222zsrrtRRtgpuEWEWc7pR0CBuNPYPT5QHbGn_Db7ICK; path=/; secure; HttpOnly
set-cookie: JSESSIONID="leTee33333PWYdSDSDweetRRtgpuc7pR0CBuNPYPT5QHbGn_Db7ICK.master-0:master-server"; Version=1; Path=/myapp; Secure; HttpOnly
status: 302
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: Undertow/1
x-xss-protection: 1; mode=block
http ssl redirect https undertow
1
That appears to be a redirect.
– Robert Harvey♦
Jan 3 at 5:32
Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost methodresponse.sendRedirect("dashboard.html" );
– Pathak
Jan 3 at 5:40
I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized.
– Robert Harvey♦
Jan 3 at 5:42
So should I need to change my LoginServlet code something like if it is http replace with https ? or there is some load balancer configuration am I missing?
– Pathak
Jan 3 at 6:01
Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem?
– Pathak
Feb 19 at 12:46
add a comment |
My questions:
1) Why do I get http as the scheme in the Location-header when the original request from the browser was made with https?
2) Is this an wildfly load balancer problem?
My Request Header is:
method: POST
scheme: https
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
content-length: 39
content-type: application/x-www-form-urlencoded
origin: https://10.43.201.207
referer: https://10.43.201.207/myapp/login.html
My Response Header is:
content-length: 0
date: Thu, 03 Jan 2019 04:55:42 GMT
location: http://10.43.201.207/myapp/dashboard.html?init=1
server: WildFly/12
set-cookie: APP_AUTH=leTPWYd1222zsrrtRRtgpuEWEWc7pR0CBuNPYPT5QHbGn_Db7ICK; path=/; secure; HttpOnly
set-cookie: JSESSIONID="leTee33333PWYdSDSDweetRRtgpuc7pR0CBuNPYPT5QHbGn_Db7ICK.master-0:master-server"; Version=1; Path=/myapp; Secure; HttpOnly
status: 302
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: Undertow/1
x-xss-protection: 1; mode=block
http ssl redirect https undertow
My questions:
1) Why do I get http as the scheme in the Location-header when the original request from the browser was made with https?
2) Is this an wildfly load balancer problem?
My Request Header is:
method: POST
scheme: https
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
content-length: 39
content-type: application/x-www-form-urlencoded
origin: https://10.43.201.207
referer: https://10.43.201.207/myapp/login.html
My Response Header is:
content-length: 0
date: Thu, 03 Jan 2019 04:55:42 GMT
location: http://10.43.201.207/myapp/dashboard.html?init=1
server: WildFly/12
set-cookie: APP_AUTH=leTPWYd1222zsrrtRRtgpuEWEWc7pR0CBuNPYPT5QHbGn_Db7ICK; path=/; secure; HttpOnly
set-cookie: JSESSIONID="leTee33333PWYdSDSDweetRRtgpuc7pR0CBuNPYPT5QHbGn_Db7ICK.master-0:master-server"; Version=1; Path=/myapp; Secure; HttpOnly
status: 302
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: Undertow/1
x-xss-protection: 1; mode=block
http ssl redirect https undertow
http ssl redirect https undertow
edited Mar 12 at 12:14
Pathak
asked Jan 3 at 5:30


PathakPathak
5111
5111
1
That appears to be a redirect.
– Robert Harvey♦
Jan 3 at 5:32
Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost methodresponse.sendRedirect("dashboard.html" );
– Pathak
Jan 3 at 5:40
I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized.
– Robert Harvey♦
Jan 3 at 5:42
So should I need to change my LoginServlet code something like if it is http replace with https ? or there is some load balancer configuration am I missing?
– Pathak
Jan 3 at 6:01
Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem?
– Pathak
Feb 19 at 12:46
add a comment |
1
That appears to be a redirect.
– Robert Harvey♦
Jan 3 at 5:32
Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost methodresponse.sendRedirect("dashboard.html" );
– Pathak
Jan 3 at 5:40
I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized.
– Robert Harvey♦
Jan 3 at 5:42
So should I need to change my LoginServlet code something like if it is http replace with https ? or there is some load balancer configuration am I missing?
– Pathak
Jan 3 at 6:01
Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem?
– Pathak
Feb 19 at 12:46
1
1
That appears to be a redirect.
– Robert Harvey♦
Jan 3 at 5:32
That appears to be a redirect.
– Robert Harvey♦
Jan 3 at 5:32
Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost method
response.sendRedirect("dashboard.html" );
– Pathak
Jan 3 at 5:40
Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost method
response.sendRedirect("dashboard.html" );
– Pathak
Jan 3 at 5:40
I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized.
– Robert Harvey♦
Jan 3 at 5:42
I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized.
– Robert Harvey♦
Jan 3 at 5:42
So should I need to change my LoginServlet code something like if it is http replace with https ? or there is some load balancer configuration am I missing?
– Pathak
Jan 3 at 6:01
So should I need to change my LoginServlet code something like if it is http replace with https ? or there is some load balancer configuration am I missing?
– Pathak
Jan 3 at 6:01
Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem?
– Pathak
Feb 19 at 12:46
Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem?
– Pathak
Feb 19 at 12:46
add a comment |
2 Answers
2
active
oldest
votes
Is the load balancer is stripping the TLS off and forwarding the request to the app as HTTP? If so, then the app, when performing a redirect, is probably using the same protocol that it's received the request on.
If that's the case, either get the app to force https
, or get the load balancer to rewrite the responses coming back through.
You may need to set proxy-address-forwarding="true"
and/or request_header_add X-Forwarded-Proto https
.
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
1
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
@Mennon and @ Subodh , we have addedproxy-address-forwarding="true"
in wildfly application server configuration , it worked
– Pathak
Mar 13 at 17:26
add a comment |
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https
, the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http
protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
- Client browser to load balancer via
https
- Load balancer to wildlfy nodes via
http
protocol . - Added
proxy-address-forwarding="true"
in wildlfy server node'shttp
listener
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54016800%2fgetting-http-in-the-location-header-when-the-original-request-was-made-over-http%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Is the load balancer is stripping the TLS off and forwarding the request to the app as HTTP? If so, then the app, when performing a redirect, is probably using the same protocol that it's received the request on.
If that's the case, either get the app to force https
, or get the load balancer to rewrite the responses coming back through.
You may need to set proxy-address-forwarding="true"
and/or request_header_add X-Forwarded-Proto https
.
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
1
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
@Mennon and @ Subodh , we have addedproxy-address-forwarding="true"
in wildfly application server configuration , it worked
– Pathak
Mar 13 at 17:26
add a comment |
Is the load balancer is stripping the TLS off and forwarding the request to the app as HTTP? If so, then the app, when performing a redirect, is probably using the same protocol that it's received the request on.
If that's the case, either get the app to force https
, or get the load balancer to rewrite the responses coming back through.
You may need to set proxy-address-forwarding="true"
and/or request_header_add X-Forwarded-Proto https
.
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
1
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
@Mennon and @ Subodh , we have addedproxy-address-forwarding="true"
in wildfly application server configuration , it worked
– Pathak
Mar 13 at 17:26
add a comment |
Is the load balancer is stripping the TLS off and forwarding the request to the app as HTTP? If so, then the app, when performing a redirect, is probably using the same protocol that it's received the request on.
If that's the case, either get the app to force https
, or get the load balancer to rewrite the responses coming back through.
You may need to set proxy-address-forwarding="true"
and/or request_header_add X-Forwarded-Proto https
.
Is the load balancer is stripping the TLS off and forwarding the request to the app as HTTP? If so, then the app, when performing a redirect, is probably using the same protocol that it's received the request on.
If that's the case, either get the app to force https
, or get the load balancer to rewrite the responses coming back through.
You may need to set proxy-address-forwarding="true"
and/or request_header_add X-Forwarded-Proto https
.
edited Mar 13 at 6:45


Subodh Joshi
5,0271360128
5,0271360128
answered Mar 12 at 14:43


Menno GroenMenno Groen
614
614
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
1
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
@Mennon and @ Subodh , we have addedproxy-address-forwarding="true"
in wildfly application server configuration , it worked
– Pathak
Mar 13 at 17:26
add a comment |
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
1
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
@Mennon and @ Subodh , we have addedproxy-address-forwarding="true"
in wildfly application server configuration , it worked
– Pathak
Mar 13 at 17:26
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP?
– Pathak
Mar 12 at 15:08
1
1
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did.
– Menno Groen
Mar 13 at 8:42
@Mennon and @ Subodh , we have added
proxy-address-forwarding="true"
in wildfly application server configuration , it worked– Pathak
Mar 13 at 17:26
@Mennon and @ Subodh , we have added
proxy-address-forwarding="true"
in wildfly application server configuration , it worked– Pathak
Mar 13 at 17:26
add a comment |
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https
, the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http
protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
- Client browser to load balancer via
https
- Load balancer to wildlfy nodes via
http
protocol . - Added
proxy-address-forwarding="true"
in wildlfy server node'shttp
listener
add a comment |
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https
, the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http
protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
- Client browser to load balancer via
https
- Load balancer to wildlfy nodes via
http
protocol . - Added
proxy-address-forwarding="true"
in wildlfy server node'shttp
listener
add a comment |
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https
, the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http
protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
- Client browser to load balancer via
https
- Load balancer to wildlfy nodes via
http
protocol . - Added
proxy-address-forwarding="true"
in wildlfy server node'shttp
listener
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https
, the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http
protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
- Client browser to load balancer via
https
- Load balancer to wildlfy nodes via
http
protocol . - Added
proxy-address-forwarding="true"
in wildlfy server node'shttp
listener
edited Mar 14 at 8:51


Subodh Joshi
5,0271360128
5,0271360128
answered Mar 14 at 7:18


PathakPathak
5111
5111
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54016800%2fgetting-http-in-the-location-header-when-the-original-request-was-made-over-http%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
That appears to be a redirect.
– Robert Harvey♦
Jan 3 at 5:32
Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost method
response.sendRedirect("dashboard.html" );
– Pathak
Jan 3 at 5:40
I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized.
– Robert Harvey♦
Jan 3 at 5:42
So should I need to change my LoginServlet code something like if it is http replace with https ? or there is some load balancer configuration am I missing?
– Pathak
Jan 3 at 6:01
Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem?
– Pathak
Feb 19 at 12:46