2013-10-14 24 views
5

Für ein Projekt verwende ich Azure-Blobspeicher, um hochgeladene Bilddateien zu speichern. Ich zeige die hochgeladenen Bilder auch auf der Website an - aber dort laufen die Dinge schief. Jede andere Anforderung an ein Bild im Blobstorage ergibt eine 400 - Multiple condition headers not supported.Azure-Blobspeicherfehler: Mehrere Bedingungsheader werden nicht unterstützt

zu diesem Fehler Lesen bis schließlich führt mich in der folgenden Dokumentation über die Angabe bedingter Request-Header: http://msdn.microsoft.com/en-us/library/windowsazure/dd179371.aspx

Diese Seite sagt folgendes über mehrere bedingte Header festgelegt wird:

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).

ich die Anfragen glauben geschickt Durch Chrome erfüllen alle Anforderungen in dieser Dokumentation beschrieben, und ich erhalte diesen Fehler.

Hat jemand Erfahrung mit Azure-Blobspeicher, der dieses Problem möglicherweise beheben kann? Ich wäre sehr dankbar!

Der Antrag wie von Chrome gesendet:

The request as sent by chrome

Die XML-Antwort, wie durch den Blob-Speicherdienst zurückgegeben: wegen Cache, mindestens

The XML response from the blob storage service

+3

Könnte es einen Proxy/Cache-Server zwischen Ihnen und Azure geben, der eigene bedingte Header hinzufügt? Was passiert, wenn Sie denselben Test von einem anderen Netzwerk (z. B. von einer Azure VM) aus durchführen? – kwill

+0

Können Sie uns auch sagen, wie groß die Dateien im Blobspeicher sind? –

+0

Die Dateien sind max. 2MB groß, einfach normales Bild hochzuladen. Der Proxy/Cache-Server war ein interessanter Vorschlag. Ich habe es von einer Azure-VM aus getestet und konnte den Fehler nicht reproduzieren. Daher nehme ich an, dass der gemeinsame Office-Bereich, in dem ich mich befinde, eigene Cache-Header hinzufügen muss. Das bringt ein kleines Problem mit sich, aber die Website, an der wir arbeiten, soll von Mitarbeitern in mittleren bis großen Unternehmen genutzt werden - die Art von Unternehmen, die auch Proxy/Cache-Server für ihr Büro-WLAN einsetzen . Können wir etwas dagegen tun? (kurz von Routing-Anfragen über unsere webrole) –

Antwort

2

Ja, es ist es war wegen Cache für mich. Ich verwende SAS, also bestand meine Lösung darin, einen zusätzlichen Parameter hinzuzufügen, um Caching zu vermeiden.

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

Der zusätzliche Parameter sollte von der Webanwendung ignoriert werden.

Verwandte Themen