Jemand zu Hause?
Mojo::IOLoop->server({port => 3000} => sub {1 2 3 4 5 6 7 8 9 10 11 12 13
Mojo::IOLoop->server({port => 3000} => sub { my ($loop, $stream) = @_; $stream->on(read => sub { my ($stream, $bytes) = @_; # Process input chunk say $bytes; # Write response $stream->write('HTTP/1.1 200 OK'); }); });
QuoteThe => operator (sometimes pronounced "fat comma") is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores. This includes operands that might otherwise be interpreted as operators, constants, single number v-strings or function calls. If in doubt about this behavior, the left operand can be quoted explicitly.
Otherwise, the => operator behaves exactly as the comma operator or list argument separator, according to context.
– http://perldoc.perl.org/perlop.html#Comma-Operator
2018-06-28T16:55:46 GwenDragonKann ich nur zustimmen.
Ich versteh auch nicht was in dem Programmbeispiel von Mojo das Fat Comma soll.
2018-06-28T17:40:41 rostiWobei mir auch das hier
schon im Halse steckenbleibt. Meine Empfehlung daher: Sich mit dem Standard CGI/1.1 befassen, des Weiteren mit HTTP/1.0 und HTTP/1.1 und einen ApacheServer aufsetzen.
MfG
Mojo::IOLoop. Bei Mojolicious geht's auch darum, dass man Apache und CGI nicht unbedingt braucht, um einen Webservice aufzusetzen: Wenn die Anwendung in Perl geschrieben ist, warum nicht auch der Webserver selbst? In dem Fall entfällt auch die Notwendigkeit von CGI. Das war nie mehr als eine pragmatische Notlösung, um zwischen Webservern und -Anwendungen zu vermitteln. Es gab lange nichts besseres und hat sich deshalb weit verbreitet, wird aber nicht über den Status eines "Informational" RFC hinauskommen, das hat die IETF ziemlich deutlich gemacht.2018-06-28T19:35:05 hajAh ja, du auch.BTW: Die Schreibweise ({key => value} => sub {}) finde ich auch unnötig verkünstelt.
2018-06-29T05:11:23 rostiWas heißt hier, die Notwendigkeit von CGI entfällt im Falle eines eigenen Webservers?
CGI/1.1 ist doch transparent! D.h., ein dem Webserver nachgelagerter Perlprozess bekommt doch sowieso sämtliche Daten in %ENV durchgereicht und kann aus STDIN lesen sowie auf STDOUT schreiben. Wozu also auch den Webserver in Perl implementieren?
mod_perl und
FastCGI, und inzwischen auch über Schnittstellenspezifikationen wie
WSGI für Python oder eben
PSGI für Perl. Für Apache gibt es die passenden Erweiterungen
mod_wsgi und mod_psgi. In all diesen Fällen ist CGI nicht erforderlich, es gibt allerdings entsprechende "Kompatibilitätsschichten" für CGI-Programme.2018-06-29T05:11:23 rostiZumal sich beliebige Webseiten um Webservices erweitern lassen. Auf meinen Domänen findest Du massenhaft solche Beispiele und das läuft alles über Apache.
MfG
QuoteIst ein Request-Header CONTENT_LENGTH > 0 gesetzt, gibt es einen Message-Body. Für den Webserver heißt das, daß soviele Bytes aus STDIN zu lesen sind, wie in CONTENT_LENGTH angegeben.
2018-06-29T07:24:15 rostiDie HTTP Spec sieht folgendes vor:
QuoteIst ein Request-Header CONTENT_LENGTH > 0 gesetzt, gibt es einen Message-Body. Für den Webserver heißt das, daß soviele Bytes aus STDIN zu lesen sind, wie in CONTENT_LENGTH angegeben.
Mojo::Message::Request-Objekt und braucht sich weder um STDIN noch um HTTP-Header zu kümmern.
QuoteHTTP ist ein Übertragungsprotokoll, da gibt es kein STDIN: Webserver lesen vom Socket. Erst die Verarbeitung durch eine CGI-Komponente liefert einen Message-Body auf STDIN ab.
QuoteThe presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers.