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;
}







0















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









share|improve this question




















  • 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


















0















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









share|improve this question




















  • 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














0












0








0








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









share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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














  • 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








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












2 Answers
2






active

oldest

votes


















1














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 .






share|improve this answer


























  • 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 added proxy-address-forwarding="true" in wildfly application server configuration , it worked

    – Pathak
    Mar 13 at 17:26



















0














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's http
    listener






share|improve this answer


























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    1














    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 .






    share|improve this answer


























    • 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 added proxy-address-forwarding="true" in wildfly application server configuration , it worked

      – Pathak
      Mar 13 at 17:26
















    1














    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 .






    share|improve this answer


























    • 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 added proxy-address-forwarding="true" in wildfly application server configuration , it worked

      – Pathak
      Mar 13 at 17:26














    1












    1








    1







    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 .






    share|improve this answer















    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 .







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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 added proxy-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






    • 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 added proxy-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













    0














    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's http
      listener






    share|improve this answer






























      0














      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's http
        listener






      share|improve this answer




























        0












        0








        0







        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's http
          listener






        share|improve this answer















        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's http
          listener







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 14 at 8:51









        Subodh Joshi

        5,0271360128




        5,0271360128










        answered Mar 14 at 7:18









        PathakPathak

        5111




        5111






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            MongoDB - Not Authorized To Execute Command

            How to fix TextFormField cause rebuild widget in Flutter

            in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith