Ik heb een CloudFront-distributie gemaakt om de statische website te bedienen. S3 is de oorspronkelijke server.
Als we nu toegang krijgen tot de CloudFront-URL, wordt deze omgeleid naar de S3-locatie.
d2s18t7gwlicql.cloudfront.net
of
test.telekha.in
In de browser wordt dit weergegeven
https://telekha-test-www. s3.ap-south-1.amazonaws.com/index.html#/dashboard
Ik verwacht https://test.telekha.in/#/dashboard
Als ik via curl toegang krijg tot https://test.telekha.in, wordt mijn index.html-document
Als ik via curl toegang krijg tot http://test.telekha.in, komt het terug
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
Maar in de browser worden zowel HTTP als HTTPS omgeleid naar https://telekha-test-www.s3.ap-south-1.amazonaws.com/index.html#/
Laat me weten hoe ik dit probleem kan oplossen.
Antwoord 1, autoriteit 100%
Snelle oplossing
Gebruik de regionale domeinnaam van uw S3-bucket om de oorsprong van de CloudFront-distributie te configureren, bijvoorbeeld: {bucket-name}.s3.{region}.amazonaws.com.
Uitleg
Volgens de discussie op AWS Developer Forums: Cloudfront-domein verwijst door naar S3 Origin URL duurt het even voordat DNS-records zijn gemaakt en gepropageerd voor nieuw gemaakte S3-buckets. Het probleem is niet zichtbaar voor buckets die zijn gemaakt in de regio VS-Oost (N. Virginia), omdat deze regio de standaardregio is (terugval).
Elke S3-bucket heeft twee domeinnamen, een globale en een regionale, d.w.z.:
- globaal—
{bucket-name}.s3.amazonaws.com - regionaal—
{bucket-name}.s3.{region}.amazonaws.com
Als u uw CloudFront-distributie configureert om de globale domeinnaam te gebruiken, zult u dit probleem waarschijnlijk tegenkomen, omdat DNS-configuratie tijd kost.
U kunt echter in de eerste plaats de regionale domeinnaam in uw oorspronkelijke configuratie gebruiken om aan dit DNS-probleem te ontsnappen.
CloudFormation-sjabloon
Als u CloudFormation gebruikt, kunt u de RegionalDomainNameuitvoerkenmerk van de AWS::S3::Bucketbron:
S3Bucket:
Type: AWS::S3::Bucket
CloudFrontDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Origins:
- DomainName: !GetAtt S3Bucket.RegionalDomainName
Meer informatie
Ik zou ook ten zeerste aanbevelen om deze blogpost over de toekomst van de verschillende padformaten van S3 te lezen:
Antwoord 2, autoriteit 46%
Ik heb het probleem gevonden. Het is met cloudfront-configuratie.
Dezeblog heeft me geholpen.
Tijdens het definiëren van de oorsprong heb ik direct S3-bucket geselecteerd. We moeten het domein van de S3-bucket invoeren, zoals telekha-test-www.s3-website.ap-south-1.amazonaws.com
Antwoord 3, autoriteit 39%
Het eerste dat u moet controleren als u denkt dat u dit ziet, is door het onderstaande curl-commando uit te voeren. Als het HTTP/1.1 307 Temporary Redirectretourneert, ziet u dit probleem.
$ curl -I https://YOUR_CF_DOMAINNAME.cloudfront.net/
HTTP/1.1 307 Temporary Redirect
Content-Type: application/xml
Content-Length: 0
Connection: keep-alive
x-amz-bucket-region: ap-southeast-2
Location: http://yourS3bucketname.s3-ap-southeast-2.amazonaws.com/
Date: Wed, 12 Jul 2017 00:20:27 GMT
Server: AmazonS3
Age: 1775
X-Cache: Hit from cloudfront
Via: 1.1 someid.cloudfront.net (CloudFront)
X-Amz-Cf-Id: someguid==
De beste beschrijving die ik van dit probleem heb gevonden is:
S3 werkt de DNS bij voor de globale REST-eindpunthiërarchie *.s3.amazonaws.com met een record dat verzoeken naar de juiste regio voor de bucket verzendt binnen een korte tijd nadat de bucket is gemaakt, en CloudFront lijkt hierop te vertrouwen voor het verzenden van de verzoeken naar de juiste plaats. Voordat die eerste update is voltooid, retourneert S3 een omleiding en CloudFront retourneert die omleiding naar de browser. ~ michael-sqlbot
Aangezien dit probleem eigenlijk te wijten is aan de interne DNS-propagatie van de S3-bucketnaam (die niet 100% duidelijk is, maar zeer waarschijnlijk lijkt) die optreedt wanneer u de bucket in S3 configureert, moet het mogelijk zijn om dit te voorkomen probleem oplossen door een openbare website in S3 te configureren voorafgaand aan het configureren van de Cloudfront-distro, en volgens de doco, configureer de openbare S3-webnaam als de cloudfront-oorsprong in plaats van de s3-bucketnaam.
Ter referentie: ik heb zowel S3-bucketnamen als S3-websitenamen geconfigureerd als Cloudfront-oorsprong en ik kan zeggen dat ze allebei werken! (uiteindelijk?)
Referenties:
Antwoord 4, autoriteit 20%
Blijkbaar is dit slechts een timingprobleem dat zichzelf na een tijdje oplost als alles correct is geconfigureerd. Meer informatie is te vinden in dezeAWS-forumthread.
Huidig geaccepteerd antwoord hier en gekoppeld aan blogartikelstelt voor om statische website voor uw S3-bucket in te schakelen en vervolgens de CF-oorsprong te wijzigen om naar die statische website te verwijzen. Deze oplossing lost het omleidingsprobleem op, maar met het neveneffect dat uw website nu beschikbaar is met zowel de CF-URL of uw aangepaste CNAME als de S3-URL.
Antwoord 5
Om het geaccepteerde antwoord uit te breiden, is met name dit gedeelte aan het einde van de blogpost waarnaar wordt verwezen, nuttig:
Ik heb een paar dagen geleden een subtiele “bug” gevonden: bij het gebruik van URL’s zoals
www.example.com/about/, Amazon S3 retourneert in feite de “index.html”
bestand in de map (omdat het is geconfigureerd als een statische website)
emmer).Het grappige is dat als je de volgende slash weglaat
(www.example.com/about), zal S3 eerst controleren of een object met de naam
“over” bestaat. Als dit niet het geval is, zal het van mening zijn dat ongeveer een
map, en zal een 301-omleiding naar about/. Tijdens gebruik
CloudFront, dit betekent dat CloudFront in feite cachet … de
omleiding in plaats van het bestand zelf! Daarom moet je ervoor zorgen
dat al uw URL’s eindigen met een schuine streep om een nutteloze te voorkomen
omleiden.