Standard-Methode für HTTP-teilweise upload Lebenslauf upload

Ich bin die Entwicklung von http-client/server framework, und auf der Suche nach der richtige Umgang mit teilweise uploads (das gleiche wie für downloads per GET-Methode mit Range-header).

Aber, ein HTTP PUT, ist nicht vorgesehen, wieder aufgenommen werden.
Und PATCH-Methode, wie ich weiß, nicht akzeptieren Range-header.

Gibt es eine Möglichkeit, dies zu behandeln von HTTP-standard (nicht mit extension-Header oder etc)?

Vielen Dank im Voraus.

  • Siehe @btimby die Antwort im Unterschied zwischen Content-Range-und Range-Header?.
  • Vielen Dank für Ihren Kommentar. Ich gesehen, die Frage nach Unterschied und Antworten. Aber, es ist nicht klar, mit teilweise GESTELLT, da einige rfcs sagen, dass Content-range-header mit SETZEN ist nicht akzeptabel. Über die PATCH-Methode, ich habe nicht gesehen, alle Informationen über die Verwendung von Content-Range mit ihm.
  • Die Skillung nicht verbieten, aber Sie müssen Fragen Sie Ihren server-das Handbuch, ob es implementiert wird oder nicht. Haben Sie vielleicht benutzerdefinierten code zu schreiben oder-Konfiguration je nach Ihren server-software und version.
  • Ich bin writting http-client und-server, von Grund auf. Natürlich kann ich mit einigen nicht-standard-Erweiterung, aber wenn es ein standard-Weg, es ist immer besser, es zu benutzen.
  • Dann erklären Sie, was Sie zu tun versuchen. Wenn Sie möchten, dass Ihre Kunden zu unterstützen, müssen Sie wissen, irgendwie ist der server Sie implementiert. Ist deine eigentliche Frage "zu erkennen, Wie ein HTTP-server unterstützt teilweise uploads mit der Content-Range header"? Wenn Sie möchten, dass Ihr server es unterstützt, nur die Umsetzung.
  • Vielen Dank für Ihren Kommentar. "Wie Sie erkennen ..." ist tatsächlich eine andere Frage. Zunächst war meine Frage, weil ich wissen muss, um standard-Methode für die partielle uploads, die akzeptabel ist meine alle gängigen http-server-Implementierungen.

InformationsquelleAutor | 2014-01-07
  1. 11

    Ich glaube, es gibt keinen standard für die partielle uploads:

    • Content-Bereich innerhalb von Anfragen ist nicht ausdrücklich verboten, in RFC2616 (http), aber auch die Formulierung bezieht sich auf es als ein response-header, die verwendet wird, in Antwort auf eine range-Anfrage
    • während Sie könnte verwenden Sie die PATCH-Methode zum aktualisieren einer vorhandenen Ressource (z.B. hinzufügen von mehreren bytes), wäre es nicht das gleiche wie eine partielle hochladen, weil die ganze Zeit die unvollständige Ressource zur Verfügung stehen würde

    Wenn man sich die Protokolle von Dropbox, google drive etc Sie alle Rollen selbst ein Protokoll zu übertragen, einzelne Dateien in mehrere Teile. Was Sie brauchen für resumeable uploads

    • eine Art und Weise, um eine unvollständige hochladen. Normale URLs-Adresse eine komplette, nicht eine partielle Ressource, und ich kenne keinen standard für die partielle Ressourcen.
    • ein Weg, um herauszufinden, den aktuellen Status der das hochladen, vielleicht auch die Prüfsummen der Teil, um sicher zu sein, dass die lokale Datei nicht ändern. Dies könnte zur Verfügung gestellt werden, die von WebDAV PROPFIND-Methode (sobald Sie in der Lage, um die Adresse unvollständig resource 🙂
    • hochladen ein Stück. Hier könnte man vielleicht verwenden, den PATCH mit content-range-header. mod_dav scheint zu erlauben, SETZEN Sie mit content-range-header (siehe http://www.gossamer-threads.com/lists/apache/users/432346)
    • einer Weise zu veröffentlichen, die Ressource, sobald es abgeschlossen ist, oder eine Weise zu definieren, im Voraus, was komplett bedeutet (e.g Größe der Ressource, Prüfsumme...)
    • HTTP-spec jetzt leider verbietet explizit die Verwendung von Contant-Range-header für die PUT-Anfragen, das wäre die einfachste und sauberste Lösung von allen.
    • Es gibt tus.io "ein neues offenes Protokoll für fortsetzbare uploads gebaut auf HTTP"
    InformationsquelleAutor Steffen Ullrich
  2. 1

    Wie bereits in einigen der Kommentare, neuere Versionen des HTTP-Spezifikation geklärt haben dieses etwas. Pro Abschnitt 4.3.4 der RFC 7231:

    Einem Ursprungs-server, mit dem SETZEN auf ein bestimmtes Ziel Ressource gesendet werden MÜSSEN
    400 (Bad Request) Antwort auf eine PUT-Anforderung mit einem
    Content-Range-header-Feld (Abschnitt 4.2 von [RFC7233]), da die Nutzlast
    ist wahrscheinlich teilweise content, der wurde fälschlicherweise als voll
    Darstellung. Teilweise content-updates sind möglich, indem Sie auf eine
    separat identifizierten Ressourcen mit dem Staat, überlappt ein Teil der
    größere Ressource oder eine andere Methode, die speziell
    definiert für partielle updates (z.B. die PATCH-Methode definiert
    [RFC5789]).

    Leider die Diskussion der range-Header Auftritt, im RFC 7233 konzentriert sich mehr oder weniger ganz auf GET-Anfragen, und RFC 5789 definiert fast nichts über den PATCH, außer, dass es insbesondere nicht erforderlich zum übertragen der gesamten Inhalte (darf aber), noch ist es erforderlich zu sein, idempotent (aber darf).

    Die helle Seite ist, dass, weil die Flecken so Locker definiert, es hat Platz für den Ansatz in einer Antwort auf eine ähnliche Frage (https://stackoverflow.com/a/6711496/7467189): ändern Sie einfach "PUT", auf "PATCH". Zwar gibt es keine Vorschrift, dass ein server zu interpretieren, ein PATCH-request mit Content-Range-header diese Weise, ist es sicherlich eine gültige interpretation, nur nicht eine, die auf gebaut werden von beliebigen Servern oder clients. Aber in Fällen wie die ursprüngliche Frage, wo die Kontrolle der beiden enden verfügbar ist, ist es zumindest ein naheliegender Ansatz und nicht gegen die geltenden Normen.

    Eine weitere überlegung ist, dass der Content-Type sollte Ausdrücken, was übertragen wird, anstatt den content-type des Unternehmens als ganzes (der RFC gibt einige Beispiele in dieser Hinsicht). Für den Inhalt ist "gepatcht" in beliebige Stücke, würde dies bedeuten application/octet-stream, zwar gibt es Szenarien, in denen der client und der server könnte mehr Inhalt-bewusst und entscheiden Sie sich zu schicken patches, die als Entitäten, die eine genauere definition (z.B. einzelne Seiten ein multi-page-image-format).

    InformationsquelleAutor Joel Aelwyn
  3. 1

    PATCH wäre eine logische Methode zu wählen, für fortsetzbare uploads: es erwartet Sie ein Medien-Typ, der angibt, wie ändern Sie die Ziel-Ressource. Auch wenn Sie nicht speziell definiert als format ausführen, patchen, multipart/byteranges gibt eine byte-Reihe und den Inhalt der Palette, so dass es entsprechend gut definiert für PATCH-Nutzlasten.

    Beispiel:

    PATCH /document HTTP/1.1
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: text/plain
Content-Range: bytes 10-21/22

1234567890
--THIS_STRING_SEPARATES--

    Diesem Beispiel uploads von zwölf bytes, die auf eine zehn-byte-offset. THIS_STRING_SEPARATES ist eine beliebige, vom Benutzer abgeholt Trennzeichen, und sollten zufällig generiert werden. Einige überschriften aus Platzgründen weggelassen, jede Zeile wird beendet mit ␍␊.

    • Das ist eine interessante Idee. Wie über dieses schreiben in einem Internet-Draft?
    • Auf Sie zu arbeiten! Es müsste die Antwort ein paar Fragen, wie, wie zu tun fortsetzbar POST (z.B. was ist, wenn ich nicht wollen, nennen Sie das Dokument, das hochgeladen wird), und wie sollte der server antwortet auf Anfragen auf Ressourcen, die nur teilweise hochgeladen.
    InformationsquelleAutor awwright
  4. 0

    Den Bereich von xxxx-yyyy-header oder die Reichweite xxxx - header mit PUT aktualisieren Teil einer Datei. Es wird unterstützt von Apache.

    Nicht verwirrt durch die Aussage im RFC 7231, dass der Content-Bereich nicht verwendet werden. Das soll verhindern, Schlechtigkeit, indem Sie Kunden-Header vom server empfangen und mit PUT, um Sie zu senden zurück an den server. Diese Achtung ist nicht relevant für die Frage der Teiltöne Stellt.

    • Haben Sie einen Verweis, um wieder den Anspruch über die Vorsatz die Aussage im RFC 7231?
    • Nein, es war nur meine interpretation des RFCs als ich studierte, damit es funktioniert. Tatsächlich nach, dass ich hatte Probleme, Apache, es zu tun korrekt, sorry.
    InformationsquelleAutor Bruce
Schreibe einen Kommentar