Risoluzione dei problemi relativi agli endpoint 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 Azure rete per la distribuzione di contenuti che restituiscono codici di stato di risposta HTTP 404.

Se in qualsiasi punto dell'articolo sono necessarie altre informazioni, è possibile contattare gli esperti di Azure nei forum MSDN e overflow dello stack relativi ad Azure. In alternativa, è anche possibile inviare un evento imprevisto del supporto tecnico di Azure. Accedere al sito del supporto di Azure e selezionare Richiesta di supporto.

Sintomo

È stato creato un profilo di rete per la distribuzione di contenuti e un endpoint, ma il contenuto non sembra essere disponibile nella rete per la distribuzione di contenuti. Gli utenti che tentano di accedere al contenuto 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, causando l'individuazione della rete per la distribuzione di contenuti nella 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

Importante

Dopo aver creato un endpoint di rete per la distribuzione di contenuti, non sarà immediatamente disponibile per l'uso, perché la propagazione della registrazione nella rete per la distribuzione di contenuti richiede tempo:

• La propagazione dei profili della rete CDN Standard di Azure con tecnologia Microsoft viene in genere completata in dieci minuti.
• Per Rete CDN di Azure Standard di Edgio e Rete CDN di Azure Premium dai profili Edgio, la propagazione viene in genere completata entro 90 minuti.

Se si completa la procedura in questo documento e si ricevono comunque risposte 404, è consigliabile attendere alcune ore e controllare nuovamente prima di aprire un ticket di supporto.

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 Archiviazione di Azure accessibile all'indirizzoHTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Se è stato possibile caricare il contenuto del file, il test è stato superato.

Avviso

Anche se questo è il modo più rapido e semplice per verificare che il file sia disponibile pubblicamente, per alcune configurazioni di rete dell'organizzazione potrebbe sembrare che il file sia disponibile pubblicamente mentre in realtà è visibile solo agli utenti della rete (anche se è ospitato in Azure). Per garantire che la situazione è diversa, eseguire il test sul file con un browser esterno, ad esempio in un dispositivo mobile non connesso alla rete dell'organizzazione, oppure in una macchina virtuale in Azure.

Controllare le impostazioni dell'origine

Dopo aver verificato che il file sia disponibile pubblicamente in Internet, verificare le impostazioni di origine. Nella portale di Azure passare al profilo di rete per la distribuzione di contenuti e selezionare l'endpoint che si sta risolvendo. 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.txtla parte hostname dell'URL è cdndocdemo.blob.core.windows.net, che è corretta. Poiché Archiviazione di Azure, le origini dell'app Web e del servizio cloud usano un valore di elenco a discesa per il campo Nome host origine, gli ortografi non corretti non sono 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 sono necessarie modifiche. Tuttavia, se il server di origine è in ascolto su una porta diversa, deve essere rappresentato 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.txtnon viene specificata una porta, quindi si presuppone che il valore predefinito 443 e le impostazioni siano corrette.

Si supponga tuttavia che l'URL del file di origine testato in precedenza sia HTTP://www.contoso.com:8080/file.txt. Si noti la parte : 8080 alla fine del segmento hostname. Tale numero indica al browser di usare la porta 8080 per connettersi al server Web in www.contoso.com, pertanto è 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.

Verrà visualizzata la pagina Configurazione dell'endpoint di 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 di rete per la distribuzione di contenuti è in ascolto solo sulle porte HTTP e HTTPS predefinite (80 e 443), indipendentemente dalle porte di origine.

Torniamo all'esempio ipotetico con HTTP://www.contoso.com:8080/file.txt. Come si ricorda, Contoso ha specificato 8080 come porta HTTP, ma si supponga anche che abbiano specificato 44300 come porta HTTPS. Se è stato creato un endpoint denominato contoso, il nome host dell'endpoint di rete per la distribuzione del contenuto sarà 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 su HTTPS, HTTPS://Contoso.azureedge.net/file.txt, provocherebbe l'uso di HTTPS sulla porta 44300 quando si 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 dei casi, questo valore deve corrispondere al nome host di origine verificato in precedenza. Un valore errato in questo campo non causa uno stato 404, ma è probabile che causi altri stati 4xx, a seconda di ciò che l'origine prevede.

Percorso origine

Infine è necessario verificare il Percorso dell'origine. Per impostazione predefinita, questo percorso è vuoto. È consigliabile 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 di restituisce HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt 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 l'endpoint richiede /donotcache/status.png dall'origine.

Ma cosa succede se non si vuole usare la rete per la distribuzione di contenuti per ogni percorso dell'origine? Si supponga di voler esporre solo il percorso del BLOB pubblico. Se si immette /publicblob nel campo Percorso origine, l'endpoint verrà inserito /publicblob prima che ogni richiesta venga effettuata all'origine. La richiesta per HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt ora accetta quindi la parte della richiesta dell'URL, /publicblob/lorem.txt e accoda /publicblob all'inizio. Risultato di 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 effettivamente HTTPS://cdndocdemo.azureedge.net/lorem.txt. Non è incluso affatto il percorso /publicblob , perché la parte della richiesta dell'URL è /lorem.txt e l'endpoint aggiunge /publicblob, generando /publicblob/lorem.txt la richiesta passata all'origine.