Problemen met compressie van Azure Content Delivery Network-bestanden oplossen
Belangrijk
Azure CDN Standard van Microsoft (klassiek) wordt op 30 september 2027 buiten gebruik gesteld. Om serviceonderbrekingen te voorkomen, is het belangrijk dat u uw Azure CDN Standard migreert van Microsoft-profielen (klassiek) naar de Azure Front Door Standard- of Premium-laag op 30 september 2027. Zie Azure CDN Standard van Microsoft (klassiek) buiten gebruik stellen voor meer informatie.
Azure CDN van Edgio is op 15 januari 2025 buiten gebruik gesteld. Zie Azure CDN van de veelgestelde vragen over buitengebruikstelling van Edgio voor meer informatie.
Dit artikel helpt u bij het oplossen van problemen met CDN-bestandscompressie.
Als u op elk gewenst moment in dit artikel meer hulp nodig hebt, kunt u contact opnemen met de Azure-experts op de MSDN Azure en de Stack Overflow-forums. U kunt ook een Azure-ondersteuningsincident indienen. Ga naar de Azure-ondersteuningssite en selecteer Ondersteuning krijgen.
Symptoom
Compressie voor uw eindpunt is ingeschakeld, maar bestanden worden niet gecomprimeerd geretourneerd.
Tip
Als u wilt controleren of uw bestanden worden gecomprimeerd, moet u een hulpprogramma zoals Fiddler of de ontwikkelhulpprogramma's van uw browser gebruiken. Controleer de HTTP-antwoordheaders die zijn geretourneerd met de netwerkinhoud voor contentlevering in de cache. Als er een header Content-Encoding
met de naam gzip, bzip2, brotli of deflate waarde is, wordt uw inhoud gecomprimeerd.
Oorzaak
Er zijn verschillende mogelijke oorzaken, waaronder:
- De aangevraagde inhoud komt niet in aanmerking voor compressie.
- Compressie is niet ingeschakeld voor het aangevraagde bestandstype.
- De HTTP-aanvraag bevat geen header die een geldig compressietype aanvraagt.
- Origin verzendt gesegmenteerde inhoud.
Stappen voor probleemoplossing
Tip
Net als bij het implementeren van nieuwe eindpunten, duurt het enige tijd om wijzigingen in de netwerkconfiguratie van inhoudslevering door te geven via het netwerk. Meestal worden wijzigingen binnen 90 minuten toegepast. Als dit de eerste keer is dat u compressie hebt ingesteld voor uw netwerkeindpunt voor contentlevering, moet u overwegen om 1-2 uur te wachten om ervoor te zorgen dat de compressie-instellingen zijn doorgegeven aan de POP's.
De aanvraag controleren
Eerst moeten we een snelle sanity-controle uitvoeren op het verzoek. U kunt de ontwikkelhulpprogramma's van uw browser gebruiken om de aanvragen weer te geven die worden gedaan.
- Controleer of de aanvraag wordt verzonden naar uw eindpunt-URL en
<endpointname>.azureedge.net
niet naar uw oorsprong. - Controleer of de aanvraag een Accept-Encoding-header bevat en de waarde voor die header gzip, deflate, brotli of bzip2 bevat.
Compressie-instellingen controleren
Navigeer naar uw eindpunt in Azure Portal en selecteer de knop Configureren .
- Controleer of compressie is ingeschakeld.
- Controleer of het MIME-type voor de inhoud die moet worden gecomprimeerd, is opgenomen in de lijst met gecomprimeerde indelingen.
Controleer de aanvraag op de oorspronkelijke server voor een Via-header
De Via HTTP-header geeft aan aan de webserver dat de aanvraag wordt doorgegeven door een proxyserver. Microsoft IIS-webservers comprimeren standaard geen antwoorden wanneer de aanvraag een Via-header bevat. Voer het volgende uit om dit gedrag te overschrijven: