http in the Location-header when the original request was made over https

apache-2.2 nginx tomcat https tomcat6

492

Solution 1

You get http in the response headers because the request that reaches Apache is HTTP - the SSL has been stripped away at the load balancer. So from what Apache sees, it's just an HTTP request.

You can work around this by setting

ServerName https://www.example.org

in the global or virtual host configuration. This will override the default http scheme so Apache will send the response you want. The documentation for ServerName mentions this.

Solution 2

I had a similar issue. Adding the following in your virtualhost config should solve the problem. Basically it would edit the http request to https

Header edit Location ^http://(.*)$ https://$1

Solution 3

http://nginx.org/docs/http/ngx_http_proxy_module.html#proxy_redirect

proxy_redirect default;
proxy_redirect http://www.example.org/ https://www.example.org/;

492

SBWork

Updated on September 18, 2022

Comments

SBWork almost 2 years
Ok, so we had some code that was working fine and passing tests fine on node 10, now following upgrading to node 11 the code now fails unit tests. Code maps over array of objects altering properties then sorts based on a string name value i.e. array.sort(a, b) => a.toLowerCase() > b.toLowerCase().

It now maps correctly but the sort does not work and returns the mapped array only without sorting, when i've tried splitting the two functions out into individual map then sort the sort returns undefined.

Have researched and tried to find some examples to see what needs to be changed but not found a great deal other than suggestions of the sort algorithm changing to timsort in v8.

simple code
```
export default places => places
   .map(place => ({
    value: place.properties.code, label: place.properties.name
   }))
   .sort((placeA, placeB) => placeA.label.toLowerCase() > 
   placeB.label.toLowerCase())
```
test array:
```
      type: 'Place',
      properties: {
        code: 'CA076757',
        name: 'Brockway'
      }
    }, {
      type: 'Place',
      properties: {
        code: 'MN486464',
        name: 'Ogdenville'
      }
    }, {
      type: 'Place',
      properties: {
        code: 'S4889785',
        name: 'North Haverbrook'
      }
    }]
```
expected result
```
      {value: 'CA076757', label: 'Brockway'},
      {value: 'S4889785', label: 'North Haverbrook'},
      {value: 'MN486464', label: 'Ogdenville'}
    ]
```
actual result
```
      {value: 'CA076757', label: 'Brockway'},
      {value: 'MN486464', label: 'Ogdenville'}.
      {value: 'S4889785', label: 'North Haverbrook'}
    ]
```
- Patrick Roberts about 5 years
  
  using > as the comparator imples the values are equal when a < b, so the implementation is allowed the freedom to swap them, or not, as the specification does not guarantee a stable sort algorithm.
- SBWork almost 5 years
  
  Thanks to all for your help and explanations as to the behaviour and why things are happening, all incredibly useful :) many many thanks
pkhamre over 10 years

Thanks for your answer. On our testing-environment we have nginx instead of Apache. Do you know how to set it there?
Andrew Schulman over 10 years

Afraid not, sorry.
jmrk about 5 years

This is sound advice, but keep in mind that localeCompare has pros and cons: on the pro side, it takes the current locale into account, which can be very much desirable (or, when running in browsers, can lead to different behavior for different users, which might be weird). On the con side, it tends to be slower than more primitive, non-locale-aware alternatives, which may or may not matter for a given use case.