3

Strange problem here. I use FullCalendar to initiate an ajax request to an endpoint on my server. Endpoint is:

https://my_website/events/?start=2019-03-31&end=2019-05-12&_=1555698739056

Note that it is explicitly https. However, when I initiate a request (that is, when Fullcalendar initiates a request), I get a 301 and a redirect to a non-https endpoint:

http://my_website/events?start=2019-03-31&end=2019-05-12&_=1555698739056

which fails because the page is loaded over https.

enter image description here

The endpoint works fine - when i load it into the browser I get the expected json output (via https). There are other ajax requests happening on this page that work correctly, and I successfully do the exact same thing with Fullcalendar elsewhere on this site (to another endpoint). It's just this one scenario that is behaving unexpectedly.

Probably noteworthy is this sits in a docker container behind nginx reverse proxy / load balancer; site config is pretty simple:

upstream docker {
    server localhost:8701;
    server localhost:8702;
  }

server {
    server_name my_website;
    location / {
      proxy_pass http://docker;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
      # proxy_set_header                HTTP_Country-Code $geoip_country_code;
        proxy_pass_request_headers      on;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/my_website/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/my_website/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    if ($host = my_website) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    server_name my_website;
    return 404; # managed by Certbot

}

And nginx log of the request is like this:

134.124.11.91 - - [19/Apr/2019:13:49:49 -0500] "GET /events/?start=2019-04-28&end=2019-06-09&_=1555699678658 HTTP/1.1" 301 0 "https://my_website" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36"

Does anyone see something I'm missing that would be causing this strange 301 redirect to a non-https endpoint?

  • 2
    The nginx configuration you posted has no redirects. Check your application. – Michael Hampton Apr 21 at 22:28
3
+25

The 301 redirect most probably comes from your backend server in the docker container. It is configured with the http://... url. Configure your application server in the container with the proper URL.

  • Why would it only be happening for a single endpoint? – Willard Solutions Apr 24 at 16:44
  • There is no way to know that without knowing what is running on the backend and how it works. – Gerald Schneider Apr 24 at 17:00
0

HTTP 301 means permanent redirect and permanent means that browser's cache is always suspect. (That's why I always use HTTP 302 for weeks on any new version.) Clear all browser cache. Alternatively, google for a guide how to remove all cached 301 responses in your browser. They are quite sticky!

If you can, always use curl -v http://x to debug, it doesn't cache anything.

  • Even if this is a browser cache issue - which I don't think it is, because it is still happening across browsers even after I clear cache/cookies - I have a few hundred users. I can't expect all of them to clear their cache – Willard Solutions Apr 19 at 21:04
  • 1
    @WillardSolutions Then try to debug directly http://docker and see if it gives you the redirect - maybe the nginx is somehow unable to intercept it... weird. – kubanczyk Apr 19 at 21:07
0

Clear the cache and change the redirection value to if ($sceme = http) { return 301 https://my_website$request_uri

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.