Multiple Request, Multipart Content Parser (gelöst) (Webframeworks, Sonstige Fragen zur Webprogrammierung mit Perl)

[thread]19853[/thread]

Multiple Request, Multipart Content Parser [gelöst]

Tags: perl5 Ähnliche Threads

Leser: 12

Articles: hide open all | hide show old branches

+7 replies
Gast janus

2015-10-21 10:40

Ich feuere mehrere Requests an meinen Server, Connection: Keep-Alive. Die Response enthält dementsprechend mehrere Response-Header-Blöcke und Message Bodies verschiedener Content-Types.

Wenn ein Browser sowas auseinanderfitzeln kann, nun, da muss es auch ein Perl-Modul geben, ich frag mich nur: Welches? Die LWP-Doku gibt gerade so ein Beispiel leider nicht her, Idee?
Last edited: 2015-10-21 11:21:48 +0200 (CEST)
- +3 replies
- GwenDragon
  
  2015-10-21 12:35
  User since
  2005-01-17
  14531 Artikel
  Admin1
  LWP liefert nach einem Request ein HTTP::Response-Objekt zurück, das beinhaltet alle Responses. Dazu gibt es die Methode previous(), um auf alle zuzugreifen;
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10
  
  use LWP::UserAgent; my $ua = LWP::UserAgent->new; my $response = $ua->get('http://search.cpan.org/'); while ($response) { say $response->$response->as_string(); # oder mach sonstwas damit $response = $response->previous(); }
  
  Für den Body des Requests gibt es HTTP::Body, da ist auch HTTP::Body::MultiPart mit drin.
  Last edited: 2015-10-21 12:40:30 +0200 (CEST)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +2 replies
  - Gast janus
    
    2015-10-21 13:11
    
    Danke Drachin :)
    
    HTTP::Body, ähm, da war ich vorhin schonmal drauf, das sieht gut aus! Mal sehen, wie das auch mit Multiple Content klarkommt.
    
    MfG
    Last edited: 2015-10-21 13:22:47 +0200 (CEST)
    - Gast janus
      
      2015-10-21 14:38
      
      Ne, doch nicht,
      
      Quote
      HTTP::Body parses chunks of HTTP POST data and supports application/octet-stream, application/json, application/x-www-form-urlencoded, and multipart/form-data.
      
      das trifft ja alles nicht zu. Ich habe hier Rohdaten, da sind mehrere Header-Blöcke, bunt gemischt mit Transfer-Encoding: chunked oder Blöcke mit Content-Length Angaben und dazu natürlich die Message-Bodies verschiedener und mehrerer Content-Types.
      
      So wie es aussieht, kommt zumindest das mit LWP erzeugte Response-Objekt mit _EINEM_ Request/Response-Zyklus klar, ich bezweifle, dass mit LWP multiple Requests mit Connection: Keep-Alive gefeuert werden können und das Response-Objekt überhaupt mit mehreren Transfer-Encodings in der Response klarkommt und diese parsen kann.
      
      Wern Beispiel hat, gerne...
      Last edited: 2015-10-21 15:02:18 +0200 (CEST)
- +2 replies
- GwenDragon
  
  2015-10-22 14:28
  
  User since
  2005-01-17
  14531 Artikel
  Admin1
  
  Um das klar zu bekommen: Du benutzt eine TCP-Verbindung über HTTP, lässt die offen, und schickst darüber nacheinander mehrere Requests und willst diese weider einlesen.
  Das läuft doch synchron ab. Auf den Request erfolgt die Response usw.
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - Gast janus
    
    2015-10-22 16:39
    2015-10-22T12:28:23 GwenDragon
    Um das klar zu bekommen: Du benutzt eine TCP-Verbindung über HTTP, lässt die offen, und schickst darüber nacheinander mehrere Requests und willst diese weider einlesen.
    Das läuft doch synchron ab. Auf den Request erfolgt die Response usw.
    
    Nein. Es läuft so ab, dass mit keep-alive sämtliche Requests in das Socket geschrieben werden. Danach wird das Socket ausgelesen und enthält sämtliche Responses => alles zusammen in einer Sequenz (Datei).
    
    Damit ein Client das wieder auseinanderkriegt, dafür gibt es das Transfer-Encoding: chunked oder einen Content-Length Header. Ein dritter Fall ist möglich, da gibt es weder/noch, so liest der Client einfach nur solange, bis nichts mehr kommt.
    
    Das Auslesen des Sockets ist wie das Deserialisieren einer Datei: Länge ermitteln, Länge lesen und so wiederholt sich das.
    
    Btw.: Die ganze LWP-Library ist ziemlich verwirrend aufgebaut. Ich frage mich z.B. warum ich aus einer Response (Datei) ein Objekt erstellen sollte, wohingegen eine zweckmäßige Datenstruktur zielführender wäre. Genauso die Frage, warum für einen Request ein Header-Objekt benötigt wird und Objekte für Cookies. Eine ziemlich verbaute Klassenhierarchie und umständlich in der Handhabe.
    
    Kurzum: Ich bin grad mal wieder an einer eigenen Klasse dran: HTTPRequest. Der Konstruktor krieg nur noch host, port, 1.0||1.1 und dann kannste ohne Umschweife Requests feuern nach dem Schema:
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9 10 11
    
    my $ro = HTTPRequest->new( host => 'www-proxy.t-online.de', http => '1.1' ) or die $!; $ro->request( method => 'PUT', uri => 'http://example.com', content => 'asdf', Connection => 'Keep-Alive'); $ro->request( method => 'GET', uri => 'http://example.com', Connection => 'Close'); my $messages = $ro->response_slice; # Array [{statuscode => '', body => '', usw.}] # alle Response-Headers sind drin in jeder {}
    
    Ohne Proxy reicht für den uri die Pfadangabe, da ist alles eins. Alle Request-Header können frei notiert werden z.B. Cookie, Accept-Encoding, Authorization-Basic usw.
    Last edited: 2015-10-22 18:00:41 +0200 (CEST)
- Gast janus
  
  2015-11-06 10:57
  
  Thread kann zu. Ich habe das alles gelöst nach alten bewährten Verfahren im Umgang mit Sequenzen. Der Algorithmus zum deserialisieren eines chunked Transfer-Encoding ist sogar in einer der RFCs beschrieben. Da die Response-Datei einer persistent Connection ggf. mehrere Antworten enthalten kann, wird der Algorithmus ganz einfach wiederholt angewandt weil eine zyklische Struktur vorliegt.
  Last edited: 2015-11-06 12:24:57 +0100 (CET)

View all threads created 2015-10-21 10:40.