Zu früh gefreut.
Bei (Binär)Dateien oberhalb von 250k scheint der Datenstrom nicht ganz beim Serverprozess angekommen zu sein.
Jedenfalls kann ich keine Dateien über 250k empfangen
v20110107 download
Zu früh gefreut.
Bei (Binär)Dateien oberhalb von 250k scheint der Datenstrom nicht ganz beim Serverprozess angekommen zu sein.
Jedenfalls kann ich keine Dateien über 250k empfangen
v20110107 download
Geändert von TheDodger (07-01-2011 um 13:08 Uhr)
Bodo
Systemadmistration UNIX
Was anderes ist mir aufgefallen, was leicht zu fixen sein kann,
wenn der GET Request auch direkt zerlegt werden soll?
Dann würde man bei "get.html?arg1=val1&arg2=val2" kein 404 erhalten.
Und im Destruktor der "writeExampleConfiguration" Call überschreibt die Config.PHP-Code:
// in QString Request::GET_Request() {
// ...
if( directory.exists( WebRoot ) && directory.isReadable() ) {
// readquery
bool hasQuery = false;
QString qs;
for (int j = 0; j < HTML_Request.size(); ++j) {
// if (hasQuery) qs += HTML_Request[j];
if (HTML_Request[j] == '?') {
hasQuery = true;
}
}
if (hasQuery) {
QStringList qsl = HTML_Request.split("?");
// ...filename = ...
// ...
// QStringList params = qsl.split("&");
} else
// filename = HTML_Request;
Bei mir ist 8080 schon belegt, daher fande ich die "User" config praktisch.
PHP-Code:
RIPCoreApplication::~RIPCoreApplication() {
/* writeExampleConfiguration(); */
markUp();
}
Geändert von zenobic (10-01-2011 um 00:33 Uhr)
Danke!
Baue ich mit ein.
Ich hatte das Thema QSettings bislang nicht so auf dem Schirm, da ich mich ja um das POST-Problem gekümmert hatte.
Meine alten configure-Klasse ist ja auch eher so ein alter Zopf, den ich mal unter Qt2 gebastelt hatte ... das Ding wird nun komplett entfernt.
Bodo
Systemadmistration UNIX
Nachtrag meinerseits ...
Das hier:
Lässt sich effektiver so lösen:PHP-Code:
for (int j = 0; j < HTML_Request.size(); ++j) {
// if (hasQuery) qs += HTML_Request[j];
if (HTML_Request[j] == '?') {
hasQuery = true;
}
}
PHP-Code:
hasQuery = ( HTML_Request.indexOf( '?' ) != -1 ) ? true : false;
Bodo
Systemadmistration UNIX
Mein Vorschlag mit dem GET Request war auch nicht ganz richtig,
mir fiel auf, dass im allgemeinen "Request handle", also vorher schon geparsed werden muss,
da dies genauso bei POST Requests der Fall sein kann.
Und man müsste noch nach Slash zerlegen und auf "is directory" prüfen,
da es auch sein kann dass der Query String (und resultierende enviroment variable: QUERY_STRING wenn cgi implementiert wird) Slashs enthält
( z.B: http://1.2.3.4/shop.cgi/categories/all ).
Ich dachte man kann es so realisieren,
dass alles was POST ist, auch ein potentieller Upload sein kann, also den POST Header parsen auf wenn vorhanden:
* "content-type" : auch "boundary=" enthalten ist, muss zerlegt werden.
* "content-disposition" : filename oder name und noch
* "content-transfer-encoding".
Gibt es denn einen Grund PUT zu implementieren?
Viele Webserver unterstützen nur POST, GET und HEAD, vorallem aus Sicherheitsgründen.
Das parsen des query-Strings habe ich aktuell noch nicht 100%ig implementiert bzw. durchdacht.
Aber ich denke, das dürfte nicht wirklich sooo kompliziert werden.
Ich hab mich mehr beim POST festgefressen.
Ich will ja gar nicht PUT implementieren!
Das POST raubt mir schon genug Nerven ...
Hier mal ein paar Beispiele
#1 mit
http://pastebin.de/13713Code:<form action="post.html" name="form" enctype="multipart/form-data" method="post">
#2 mit
http://pastebin.de/13714Code:<form action="post.html" name="form" method="post">
Also 2 völlig verschiedene Wege um die POST-Variablen auszuwerten ...
Bei #1 fällt dann auch auf, dass 'Content-Disposition: form-data; ...' mehrmals vorkommt.
Ich bin ja so vorgegangen, dass ich vom letzten Eintrag anfange zu parsen. Scheinbar funktioniert das aber nicht wie gewünscht ...
Bodo
Systemadmistration UNIX
Ja, man braucht wahrscheinlich mindestens 2 Schritte um postdata zu parsen.
Aber dass sind, soweit ich weiss, auch die einzigen 2 Fälle die auch andere Webserver abfangen.
Ich glaube so könnte der Ablauf funktionieren:
Allgemein Header splitten auf ':' zum Auslesen.
Wenn POST dann (content-length speichern etc.) im
HEADER['content-type'] auf "boundary" oder "multipart" testen.
Wenn es kein Multipart ist und boundary enthält, kann man die Parameter (wie #1)
zerlegen.
Ansonsten boundary speichern ( #2 ), dann muss man parsen, z.B. mit spiltten nach boundary, diese beginnen mitund in einer Schleife analysieren, wenn dann ein filename enthalten ist, muss dies temporär gespeichert werden, z.B. nach /tmp mit einem "tmp name".Code:"\r\n--" + boundary
#1 Nach new 2 NewLines "\r\n\r\n" und als QUERY_STRING speichern,
(ggf. nach & und = zerlegen)
#2 mit boundary, dann boundaries zerlegen.
Aus der 'content-disposition' Line name und ggf. filename extrahieren,
ggf. alles nach Semikolon auf '=' splitten.
Wenn zwischen den Boundaries 'content-type' vorkommt, dann die eingelesen Chars (data)
als Datei speichern, ansonsten als Postdata in z.B. POST[name] = data .
Ich denke das kann auch richtig Spass machen
Geändert von zenobic (10-01-2011 um 19:41 Uhr)
Eventuell lässt sich auch QUrl zum parsen der GET URL heranziehen, das hätte u.A. hasQuery()
Ciao,
_
Qt/KDE Entwickler
Debian Benutzer
Naja .. Spaß machen ...
Scheinbar habe ich Probleme beim 'Auseinandernehmen' der Request-Daten:
Nach 'Content-Length' müssten es ~280k sein.Code:[22:49:26:261] [ Debug] : HEADER: [595] 'POST /post.html HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110102 Gentoo Firefox/3.6.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.7,de-de;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://localhost:8080/ X-Behavioral-Ad-Opt-Out: 1 X-Do-Not-Track: 1 Content-Type: multipart/form-data; boundary=---------------------------1525561818437990015185174710 Content-Length: 278153' [22:49:26:261] [ Debug] : Request: 'POST' - 'post.html' - 'HTTP/1.1' [22:49:26:261] [ Debug] : Content-Disposition found ... [22:49:26:261] [ Debug] : Request-Size '56749' [22:49:26:261] [ClassDebug] : void MultiPart::init() [22:49:26:262] [ Debug] : capacity 57344 [22:49:26:262] [ Debug] : i think, we can have 1 attachments [22:49:26:262] [ Debug] : name 'file1' [22:49:26:262] [ Debug] : filename '01ba2c47cf8ceb8a8d23e565dcec297b-d31oky4.jpg' [22:49:26:262] [ Debug] : type 'image/jpeg' [22:49:26:262] [ Debug] : size '56270' [22:49:26:262] [ Debug] : datetime '10.01.2011-22:49:26:262' [22:49:26:262] [ Debug] : md5 '684f129518e241c154fdaa5d5b8bba3d'
Nach meinem auseinander-cut-en habe ich nur 56k übrig.
Ich krieg 'n Fön
update #1
Ich glaube fast, der socket in Request.cpp bekommt die Daten nicht fix genug und wird geschlossen, bevor alles bei ihm gelandet ist.
Gibt es keine Möglichkeit das anders zu gestalten?
update #2
aktuelle Version
Bodo
Systemadmistration UNIX
Lesezeichen