Thomas König: Frage zum Wiki-Artikel ‚File Upload‘

problematische Seite

Hallo zusammen,

bei diesem Dateiupload fehlt mir der wichtigste Schritt. Das tatsächliche Ablegen einer Datei auf dem Server mit einem vordefiniertem Pfad. Hier wird nur die Dateiauswahl beschrieben. Ich würde gerne eine/e Bild/Datei clientseitig auf dem (eigenen) IIS ablegen. Hat da jemand ne Lösung?

Gruß Tommy

  1. problematische Seite

    Hallo Thomas,

    in diesem Fall heißt die Antwort "kommt drauf an". Du hast eine ganze Menge an Möglichkeiten.

    Grundsätzlich ist das Speichern einer Datei über die HTTP Verben PUT und POST möglich, zumindest war das mal die Idee von HTTP, das setzt aber entsprechende Autorisierungen voraus. Ich hab's noch nie versucht, eine nackige Datei an einen IIS zu PUTten. Vielleicht macht er es sogar wenn der User, mit dem Du den Request durchführst, Schreibrecht auf den Ordner hat in dem das Web liegt (bzw. einen Upload-Unterordner). Problem in dem Fall ist aber, dass auf dem Server kein Signal ausgelöst wird dass jemand einen Upload gemacht hat. D.h. Du musst die Weiterverarbeitung selber irgendwie anstoßen (mit der Maus am Arm, mit der Aufgabenplanung oder über einen selbstgeschrieben Windows Service).

    Die andere Möglichkeit ist ein serverseitiges Script - im Falle eines IIS möglicherweise ASP.NET - das beim POST abgesprochen wird und das den am Request anhängenden MIME Datenstrom ausliest, ihn speichert und dann die Weiterverarbeitung anstößt. Um zu sagen, wie man das macht, reicht selbst der Hinweis ".net" nicht, weil es da wieder diverse Modelle gibt (Webforms, Webservice, MVC, und mehr). Wenn Du mit anderen Sprachen arbeitest (IIS unterstützt da einiges), musst Du es natürlich mit den Mitteln dieser Sprache tun.

    Gruß Rolf

    1. problematische Seite

      Grundsätzlich ist das Speichern einer Datei über die HTTP Verben PUT und POST möglich,

      Jeder Webserver der CGI/1.1 unterstützt setzt eine Umgebungsvariable CONTENT_LENGTH wenn im HTTP-Request ein Message.Body gesendet wurde -- und das ist von der Request-Methode völlig unabhängig. Des Weiteren legt der Webserver die Bytesequenz des Message-Body um auf STDOUT in Richtung CGI-Pozess welcher den Datenstrom somit aus STDIN lesen kann wobei CONTENT_LENGTH exact die Anzahl der zu lesenden Bytes angibt.

      MfG

      1. problematische Seite

        Grundsätzlich ist das Speichern einer Datei über die HTTP Verben PUT und POST möglich,

        Jeder Webserver der CGI/1.1 unterstützt setzt eine Umgebungsvariable CONTENT_LENGTH wenn im HTTP-Request ein Message.Body gesendet wurde -- und das ist von der Request-Methode völlig unabhängig.

        Ohne zu wissen, was Du da genau wieder basteln möchtest: bei GET musst Du aufpassen, nicht in Längenbeschränkungen zu laufen. Die Methode ist also nicht egal. Das hast Du aber implizit mit Deinem Posting zum Ausdruck gebracht.

        1. problematische Seite

          Grundsätzlich ist das Speichern einer Datei über die HTTP Verben PUT und POST möglich,

          Jeder Webserver der CGI/1.1 unterstützt setzt eine Umgebungsvariable CONTENT_LENGTH wenn im HTTP-Request ein Message.Body gesendet wurde -- und das ist von der Request-Methode völlig unabhängig.

          Ohne zu wissen, was Du da genau wieder basteln möchtest: bei GET musst Du aufpassen, nicht in Längenbeschränkungen zu laufen. Die Methode ist also nicht egal. Das hast Du aber implizit mit Deinem Posting zum Ausdruck gebracht.

          Natürlich kannst Du auch mit GET einen Message Body senden -- und das ohne Längenbegrenzung. Die Request-Methode ist nur eine Bezeichnung ohne irgendwelche Verbindlichkeiten, seitens HTTP ist die Bezeichnung völlig Wurscht. Praktisch kannst Du eine Request-Methode auch zITRONe nennen und in einem Request gleichzeitig Daten per Message-Body und im URI senden.

          Da kommts nur auf den Webserver an, inwiefern er beliebige -- nicht RFC gerechte -- Bezeichner für die Request-Methode toleriert. Wäre ja noch schöner wenn ich mich mit dem Namen der Requestmethode einschränken müsste ;)

          1. problematische Seite

            Natürlich kannst Du auch mit GET einen Message Body senden -- und das ohne Längenbegrenzung.

            http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request#answer-2659995

            Zitat: "If you need to send large data, then better use POST instead of GET. Its limit is much higher, but more dependent on the server used than the client."

            1. problematische Seite

              Natürlich kannst Du auch mit GET einen Message Body senden -- und das ohne Längenbegrenzung.

              http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request#answer-2659995

              Zitat: "If you need to send large data, then better use POST instead of GET. Its limit is much higher, but more dependent on the server used than the client."

              Du hast nicht verstanden was ich gestern schrieb: Aus der Sicht des Protokolls HTTP ist die Bezeichnung für die Requestmethode bedeutungslos. Ein Unterschied ergibt sich lediglich daraus, ob den Request-Headers ein Message-Body folgt oder nicht.

              Das heißt, dass es auch dann einen Message-Body mit unbegrenzter Länge geben kann wenn die Request-Methode als GET bezeichnet wird.