2015-07-22 12 views
8

Ich habe eine REST-API, die eine Audiodatei über einen HTTP-Post akzeptiert. Die API unterstützt Transfer-Encoding: chunked request header, so dass die Datei in Teilen hochgeladen werden kann, während sie von einem Rekorder erstellt wird, der auf dem Client ausgeführt wird. Auf diese Weise kann der Server die Datei so verarbeiten, wie sie ankommt, um die Leistung zu verbessern. Zum Beispiel:HTTP POST mit XHR mit Chunked Transfer Encoding

HTTP 1.1 POST .../v1/processAudio

Transfer-Encoding: Chunked

[Chunk 1 256 Bytes] (Server die Verarbeitung beginnt, wenn eintrifft)

[ Chunk 2 256 Bytes]

[Chunk 3 256 Bytes]

...

Die Audiodateien sind in der Regel kurz und haben eine Größe von etwa 10K bis 100K. Ich habe C# und Java-Code, der funktioniert, damit ich weiß, dass API funktioniert. Allerdings kann ich nicht scheinen, die Aufnahme und das Hochladen in einem Browser mit Javascript zu arbeiten.

Hier ist mein Test-Code, der eine POST tut mit Transfer-Encoding auf localhost:

<html> 
 
<script type="text/javascript"> 
 
    function streamUpload() { 
 
    var blob = new Blob(['GmnQPBU+nyRGER4JPAW4DjDQC19D']); 
 
    var xhr = new XMLHttpRequest(); 
 
    // Add any event handlers here... 
 
    xhr.open('POST', '/', true); 
 
    xhr.setRequestHeader("Transfer-Encoding", "chunked"); 
 
    xhr.send(blob); 
 
    } 
 
</script> 
 

 
<body> 
 
    <div id='demo'>Test Chunked Upload using XHR</div> 
 
    <button onclick="streamUpload()">Start Upload</button> 
 
</body> 
 

 
</html>

Das Problem ist, dass ich in Chrome

die folgenden Fehlern bin Empfang Weigerte sich, den unsicheren Header "Transfer-Encoding" zu setzen

streamUpload @ uploadTest.html: 14 onclick @ uploadTest.html: 24

Nach dem Betrachten der XHR-Dokumentation bin ich immer noch verwirrt, weil es nicht über unsible Anfrage Header spricht. Ich frage mich, ob es möglich ist, dass XHR nicht erlaubt oder implementieren Transfer-Encoding: Chunked für HTTP POST?

Ich habe mit mehreren XHR.send() -Anfragen und WebSockets auf Arbeitsumgebungen geschaut, aber beide sind unerwünscht, weil es erhebliche Änderungen an den Server-APIs erfordert, die bereits vorhanden sind, einfach, stabil und funktionieren. Das einzige Problem ist, dass wir nicht POST von einem Browser mit psedo-Streaming über Transfer-Encoding: Chunked Request-Header scheinen können.

Alle Gedanken oder Ratschläge wären sehr hilfreich.

+0

Sie dürfen diese Kopfzeile nicht festlegen. Es wird vom User Agent gesteuert. Überprüfen Sie die w3-Spezifikation dafür hier: http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method, speziell dort, wo es heißt: "Die obigen Header werden vom User-Agent gesteuert, damit sie diese Aspekte kontrollieren können des Verkehrs ". –

Antwort

0

Wie in einem Kommentar erwähnt, dürfen Sie diesen Header nicht festlegen, da er vom Benutzeragenten gesteuert wird.

Für den vollen Satz von Headern finden 4.6.2 The setRequestHeader() method von W3C XMLHttpRequest Stufe 1 und beachten Sie, dass Transfer-Encoding einer der Header, die vom Benutzerprogramm gesteuert werden, um es auf die Aspekte des Verkehrs kontrollieren zu lassen.

  • Accept-Charset
  • Accept-Encoding
  • Access-Control-Request-Header
  • Access-Control-Request-Methode
  • Verbindung
  • Content-Length
  • Plätzchen
  • Cookie2
  • Datum
  • DNT
  • Erwarten
  • Host-
  • Keep-Alive
  • Herkunft
  • Referer
  • TE
  • Trailer
  • Transfer-Encoding
  • Upgrade-
  • User-Agent
  • Via

Es gibt eine ähnliche Liste in der WHATWG API Lebensstandard holen. https://fetch.spec.whatwg.org/#terminology-headers