Risoluzione dei problemi relativi agli endpoint di Rete per la distribuzione di contenuti di Azure che restituiscono un codice di stato 404

Questo articolo consente di risolvere i problemi relativi agli endpoint di Rete per la distribuzione di contenuti di Azure che restituiscono codici di stato di risposta HTTP 404.

Se si ha bisogno di ulteriore aiuto in qualsiasi punto di questo articolo, è possibile contattare gli esperti di Azure sui forum MSDN Azure e Stack Overflow. In alternativa, è anche possibile aprire un evento di supporto di Azure. Accedere al sito del supporto di Azure e selezionare Richiesta di supporto.

Sintomo

È stato creato un profilo e un endpoint della rete per la distribuzione di contenuti, ma sembra che il contenuto non sia disponibile nella rete per la distribuzione di contenuti. Gli utenti che provano ad accedere ai contenuti tramite l'URL della rete per la distribuzione di contenuti ricevono un codice di stato HTTP 404.

Causa

Le cause possono essere diverse, ad esempio:

• L'origine del file non è visibile alla rete per la distribuzione di contenuti.
• L'endpoint non è configurato correttamente, per cui la rete per la distribuzione di contenuti cerca in una posizione errata.
• L'host rifiuta l'intestazione host dalla rete per la distribuzione di contenuti.
• L'endpoint non ha avuto tempo per propagarsi in tutta la rete per la distribuzione di contenuti.

Passaggi per la risoluzione dei problemi

Controllare il file di origine

In primo luogo, verificare che il file da memorizzare nella cache sia disponibile nel server di origine e accessibile pubblicamente In Internet. Il modo più rapido per eseguire questa operazione consiste nell'aprire un browser in una sessione privata o anonima e passare direttamente al file. Digitare o incollare l'URL nella casella dell'indirizzo e verificare che restituisca il file desiderato. Si supponga, ad esempio, di avere un file in un account di archiviazione di Azure accessibile in HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Se è stato possibile caricare il contenuto del file, il test è stato superato.

Controllare le impostazioni dell'origine

Dopo aver verificato che il file sia disponibile pubblicamente in Internet, verificare le impostazioni di origine. Nel portale di Azure, passare al profilo della rete per la distribuzione di contenuti e selezionare l'endpoint di cui risolvere i problemi. Nella pagina Endpoint visualizzata selezionare l'origine.

Viene visualizzata la pagina Origine.

Tipo di origine e nome host

Verificare che i valori nei campi Tipo di origine e Nome host dell'origine siano corretti. In questo esempio, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, la parte del nome host dell'URL è cdndocdemo.blob.core.windows.net, che è corretta. Poiché le origini di Archiviazione di Azure, App Web e Servizio cloud usano un valore di un elenco a discesa per il campo Nome host origine, l'ortografia errata non è un problema. Se si usa un'origine personalizzata, verificare tuttavia che il nome host sia stato digitato correttamente.

Porte HTTP e HTTPS

Controllare le porte HTTP e HTTPS. Nella maggior parte dei casi, 80 e 443 sono corretti e non saranno necessarie modifiche. Tuttavia, se il server di origine è in ascolto su una porta diversa, tale porta deve essere rappresentata qui. Se non si è certi, visualizzare l'URL per il file di origine. Le specifiche HTTP e HTTPS indicano le porte 80 e 443 per impostazione predefinita. Nell'URL di esempio, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, non è specificata una porta, quindi viene presupposto il valore predefinito 443 e le impostazioni sono corrette.

Si supponga tuttavia che l'URL per il file di origine testato in precedenza sia HTTP://www.contoso.com:8080/file.txt. Si noti la parte :8080 alla fine del segmento del nome host. Tale numero indica al browser di usare la porta 8080 per connettersi al server Web all'indirizzo www.contoso.com, per cui è necessario immettere 8080 nel campo Porta HTTP. È importante notare che queste impostazioni della porta hanno effetto solo sulla porta usata dall'endpoint per recuperare informazioni dall'origine.

Controllare le impostazioni dell'endpoint

Nella pagina Endpoint selezionare il pulsante Configura.

Appare la pagina Configura dell'endpoint della rete per la distribuzione di contenuti.

Protocolli

In Protocolliverificare che sia selezionato il protocollo usato dai client. Lo stesso protocollo usato dal client è quello usato per accedere all'origine, quindi è importante che le porte di origine siano configurate correttamente nella sezione precedente. L'endpoint della rete per la distribuzione dei contenuti è in ascolto solo sulle porte HTTP e HTTPS (80 e 443) predefinite, indipendentemente dalle porte di origine.

Si torni all'esempio ipotetico con HTTP://www.contoso.com:8080/file.txt. Come indicato in precedenza, Contoso ha specificato 8080 come propria porta HTTP, ma si supponga che sia stata specificata la porta 44300 come propria porta HTTPS. Se è stato creato un endpoint denominato contoso, il nome host dell'endpoint della rete per la distribuzione di contenuti sarebbe contoso.azureedge.net. Una richiesta per HTTP://Contoso.azureedge.net/file.txt è una richiesta HTTP, quindi l'endpoint userà HTTP sulla porta 8080 per recuperarlo dall'origine. Una richiesta sicura tramite HTTPS, HTTPS://Contoso.azureedge.net/file.txt, farebbe sì che l'endpoint usi HTTPS sulla porta 44300 quando recupera il file dall'origine.

Intestazione host di origine

L'opzione Intestazione host di origine è il valore dell'intestazione host inviato all'origine con ogni richiesta. Nella maggior parte, questo valore deve essere identico al Nome host origine verificato in precedenza. Un valore non corretto in questo campo non causa stati 404, ma è probabile che causi altri stati 4xx, a seconda di quanto previsto dall'origine.

Percorso origine

Infine è necessario verificare il Percorso dell'origine. Per impostazione predefinita, questo percorso è vuoto. Usare questo campo solo se si vuole limitare l'ambito delle risorse ospitate dall'origine da rendere disponibili nella rete per la distribuzione di contenuti.

Nell'endpoint di esempio tutte le risorse dell'account di archiviazione dovevano essere disponibili e di conseguenza il campo Percorso dell'origine è stato lasciato vuoto. Pertanto, una richiesta a HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt genera una connessione dall'endpoint a cdndocdemo.core.windows.net che richiede /publicblob/lorem.txt. Analogamente, una richiesta per HTTPS://cdndocdemo.azureedge.net/donotcache/status.png genera la richiesta dell'endpoint /donotcache/status.png dall'origine.

Cosa accade se non si vuole usare la rete per la distribuzione di contenuti per ogni percorso nell'origine? Supponiamo che si voglia solo esporre il percorso publicblob. Se si immette /publicblob nel campo Percorso origine, l'endpoint inserisce /publicblob prima di ogni richiesta effettuata all'origine. La richiesta per HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt, quindi, ora accetta la parte di richiesta dell'URL, /publicblob/lorem.txt, e accoda /publicblob all'inizio. Viene quindi eseguita una richiesta per /publicblob/publicblob/lorem.txt dall'origine. Se tale percorso non viene risolto in un file effettivo, l'origine restituisce uno stato 404. L'URL corretto per recuperare lorem.txt in questo esempio sarebbe in realtà HTTPS://cdndocdemo.azureedge.net/lorem.txt. Non si include affatto il percorso /publicblob perché la parte della richiesta dell'URL è /lorem.txt e l'endpoint aggiunge /publicblob, che determina il passaggio della richiesta /publicblob/lorem.txt all'origine.