web-dev-qa-db-ja.com

httpsからhttpにリダイレクトしますか？

ここで奇妙な問題。 FullCalendarを使用して、サーバー上のエンドポイントへのajaxリクエストを開始します。エンドポイントは次のとおりです。

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

明示的にhttpsであることに注意してください。ただし、リクエストを開始すると（つまり、Fullcalendarがリクエストを開始すると）、301とhttps以外のエンドポイントへのリダイレクトが表示されます。

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

ページがhttps経由で読み込まれるため、失敗します。

enter image description here

エンドポイントは正常に機能します-ブラウザーにロードすると、期待されるjson出力が得られます（https経由）。このページで正しく機能する他のajaxリクエストが発生しており、このサイトの他の場所（別のエンドポイント）でFullcalendarを使用してまったく同じことを正常に実行しています。予期しない動作をしているのは、この1つのシナリオだけです。

おそらく注目に値するのは、これがnginxリバースプロキシ/ロードバランサーの背後にあるDockerコンテナにあることです。サイトの構成は非常に簡単です。

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

}

そして、リクエストのnginxログは次のようになります：

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、Geckoなど）Chrome/73.0.3683.103 Safari/537.36 "

この奇妙な301がhttps以外のエンドポイントにリダイレクトされる原因となる、私が見逃している何かを見た人はいますか？

nginxhttps301-redirectajax
3
Willard Solutions

301リダイレクトは、Dockerコンテナ内のバックエンドサーバーから送信される可能性があります。 http://...urlで構成されます。コンテナ内のアプリケーションサーバーを適切なURLで構成します。

3
Gerald Schneider

HTTP 301は永続的なリダイレクトを意味し、永続的なはブラウザのキャッシュが常に疑わしいことを意味します。 （そのため、新しいバージョンでは常にHTTP 302を数週間使用します。）すべてのブラウザキャッシュをクリアします。または、ブラウザでキャッシュされたすべての301応答を削除する方法のガイドをグーグルで検索してください。彼らはかなり粘着性があります！

可能であれば、常にcurl -v http://xを使用してデバッグし、何もキャッシュしません。

0
kubanczyk

キャッシュをクリアし、リダイレクト値をif（$ sceme = http）{return 301 https：// my_website $ request_uriに変更します

0
Abhijith