2013-10-14 12 views
5

Per un progetto, sto utilizzando la memoria BLOB di Azure per archiviare i file di immagine caricati. Sto anche visualizzando le immagini caricate sul sito Web - tuttavia, è qui che le cose vanno male. Ogni altra richiesta a un'immagine in blobstorage produce un 400 - Multiple condition headers not supported.Errore di archiviazione BLOB di Azure: le intestazioni di più condizioni non sono supportate

lettura su questo errore alla fine mi porta alla seguente documentazione sulla specifica condizionali intestazioni di richiesta: http://msdn.microsoft.com/en-us/library/windowsazure/dd179371.aspx

Quella pagina dice il seguente su come specificare più intestazioni condizionali:

If a request specifies both the If-None-Match and If-Modified-Since headers, the request is evaluated based on the criteria specified in If-None-Match.

If a request specifies both the If-Match and If-Unmodified-Since headers, the request is evaluated based on the criteria specified in If-Match.

With the exception of the two combinations of conditional headers listed above, a request may specify only a single conditional header. Specifying more than one conditional header results in status code 400 (Bad Request).

Credo che le richieste inviate da Chrome soddisfare tutti i requisiti delineati da questa documentazione, eppure ricevo quell'errore.

Qualcuno ha esperienza con lo storage BLOB di Azure che potrebbe aiutare a risolvere questo problema? Sarei molto grato!

La richiesta come inviato da Chrome:

The request as sent by chrome

La risposta XML come restituito dal servizio di archiviazione blob:

The XML response from the blob storage service

+3

Potrebbe esserci un server proxy/cache tra te e Azure che sta aggiungendo i propri header condizionali? Cosa succede quando si esegue lo stesso test da una rete diversa (ad es. Da una VM di Azure)? – kwill

+0

Inoltre, puoi dirci quanto sono grandi i file memorizzati nella memoria BLOB? –

+0

I file sono max. 2mb di dimensioni, solo il normale caricamento dell'immagine davvero. Il server proxy/cache era un suggerimento interessante. L'ho provato da una macchina virtuale di Azure e non ero in grado di riprodurre l'errore, quindi presumo che lo spazio ufficio condiviso in cui sono inserito debba aggiungere le proprie intestazioni della cache. Questo aggiunge un po 'un problema a sé stante, tuttavia, il sito Web su cui stiamo lavorando dovrebbe essere utilizzato dai dipendenti di aziende medio-grandi - il tipo di aziende che potrebbero utilizzare server proxy/cache per il loro ufficio WiFi . C'è qualcosa che potremmo fare per aggirare questo? (a corto di richieste di routing tramite la nostra webrole) –

risposta

2

Sì, è a causa della cache, almeno era a causa della cache per me. Sto usando SAS, quindi la mia soluzione era aggiungere un parametro extra per evitare il caching.

/// token = SharedAccessSignature 
    string tick = $"&{ DateTimeOffset.UtcNow.Ticks}"; 
    Uri url = new Uri(file.StorageUri.PrimaryUri.ToString() + token + tick); 

Il parametro aggiuntivo deve essere ignorato dall'applicazione Web.

Problemi correlati