![]() |
WinSocket Upload Daten per Formular empfangen (über Browser)
Hallo,
ich habe mir einen Web-Server gebaut, mit WinSockets (D3). Anfordern und Senden von Daten funktioniert. Er läuft als ServerType:=stNonBlocking. Auch das Auslesen vom Formularen klappt im Test, sprich normale Formulardaten werden entgegengenommen. Formular auf der html-Seite
Code:
Die Daten empfange ich über den Links selbst im OnClientRead:
<form action="formulardata.fd" method="get">
<input type="text" name="input1" value=""> ... </form> Socket.ReceiveText:
Code:
GET /formulardata.fd?input1=Input+test+1+%F6%E4%FC%DF+%F6%E4%FC%DF&pass=passworttest&sel1=1&text1=+%F6%E4%FC%DF%0D%0A+Test%0D%0A+%F6%E4%FC%DF%0D%0A+%D6%C4%DC%0D%0A+&sendbutt=senden HTTP/1.1
Accept: */* Referer: [url]http://h2o/formular.htm[/url] Accept-Language: de UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: h2o Connection: Keep-Alive das gleiche Spiel bei method="Post" wobei hier die Daten im hinteren Ende stecken. Socket.ReceiveText:
Code:
So und nun zum spannenden Teil (und zur Frage):
POST /formulardata.fd HTTP/1.1
Accept: */* Referer: [url]http://h2o/formular.htm[/url] Accept-Language: de Content-Type: application/x-www-form-urlencoded UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: h2o Content-Length: 327 Connection: Keep-Alive Cache-Control: no-cache input1=Input+test+1+%F6%E4%FC%DF+%F6%E4%FC%DF&pass=passworttest&sel1=1&text1=+%F6%E4%FC%DF%0D%0A+Test%0D%0A+%F6%E4%FC%DF%0D%0A+%D6%C4%DC%0D%0A+&Klickmich=%3CP%3E%3CIMG+id%3Dsbild+height%3D115+alt%3Dtumbnail+src%3D%22testbilder%2Frosetump.jpg%22+width%3D153+name%3Dsbild%3E%3CBR%3E%3CB%3EEin+Bild+%5Bsend%5D%3C%2FB%3E+%3C%2FP%3E Wenn ich eine Formular mit upload einer Datei habe wo landen dann die Daten? Im thesocket.ReceiveLength stehen sie nicht der ist 0. thesocket:TCustomWinSocket bieten jetzt auch option/Buffer wo es versteckt sein könnte aber ohne Längenangabe? Socket.ReceiveText:
Code:
html dazu:
POST /formulardata.fd HTTP/1.1
Accept: */* Referer: [url]http://h2o/formular.htm[/url] Accept-Language: de Content-Type: multipart/form-data; boundary=---------------------------7d71b32b5a029c UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: h2o Content-Length: 163 Connection: Keep-Alive Cache-Control: no-cache -----------------------------7d71b32b5a029c Content-Disposition: form-data; name="senderbutton" Anfrage senden -----------------------------7d71b32b5a029c--
Code:
Oder muss ich die hochzuladene Daten vom Webbrowser anfordern?
<form action="formulardata.fd" method="post" enctype="multipart/form-data">
<input type="file" size="30" accept="text/*"> <input type="submit" name="senderbutton" style=""> </form> Die Daten müssten doch im Socket.ReceiveBuf stehen oder? |
Upload Daten empfangen (http)
so hab weiter experimentiert. Warum socket.ReceiveLength=0 ist - hab ja die Daten per Socket.ReceiveText ausgelesen und dann wird socket.ReceiveLength=0. Einige Daten bekomme ich ja z.B.
Delphi-Quellcode:
aber das sind ja nicht das Bild was ich uploaden wollte... weitersuch...
Content-Length: 159
Connection: Keep-Alive Cache-Control: no-cache -----------------------------7d7ff26305b2 Content-Disposition: form-data; name="senderbutton" Anfrage senden -----------------------------7d7ff26305b2-- eigendlich sollte bei "Content-Disposition:" sowas stehen "attachment; filename=bild.jpg" weitersuch... hmm, ich hab auch die Vermutung das der Lese-Puffer voll ist und ich nochmal lesen müsste? also zum Client ein OK (was?) senden und gucken ob noch mehr Daten ankommen? vielleicht kann ich kein Server.ServerType:=stNonBlocking; dazu nehmen, nur dann müsste ich den Server umschreiiben? Quelle: ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz