QHttpServer Class

Dokumentation zu Mitgliedsfunktionen

[explicit] QHttpServer::QHttpServer(QObject *parent = nullptr)

Erstellt eine Instanz von QHttpServer mit dem übergeordneten parent.

[override virtual noexcept] QHttpServer::~QHttpServer()

Löscht einen „ QHttpServer “.

template <typename Functor> void QHttpServer::addAfterRequestHandler(const QObject *context, Functor &&slot)

Registrieren Sie einen „ context “ und einen „ slot “, die nach der Bearbeitung jeder Anfrage aufgerufen werden sollen.

Die ` slot ` muss die Signatur ` void (*)(const QHttpServerRequest &, QHttpServerResponse &)` implementieren.

slot kann auch ein Funktionszeiger, ein nicht veränderbliches Lambda oder ein beliebiges anderes kopierbares, aufrufbares Objekt mit dem const-Aufrufoperator sein. In diesem Fall ist context ein Kontextobjekt, und der Handler bleibt gültig, bis das Kontextobjekt zerstört wird.

Beispiel:

server.addAfterRequestHandler(&server, [] (const QHttpServerRequest &req, QHttpServerResponse &resp) {
    auto h = resp.headers();
    h.append(QHttpHeaders::WellKnownHeader::Cookie, "PollyWants=Cracker");
    resp.setHeaders(std::move(h));
}

void QHttpServer::clearMissingHandler()

Setzt den Handler auf den Standard-Handler zurück, der Antworten mit dem Status „ 404 Not Found “ generiert.

Siehe auch „ setMissingHandler “.

template <typename Rule = QHttpServerRouterRule, typename Functor> Rule *QHttpServer::route(const QString &pathPattern, QHttpServerRequest::Methods method, const QObject *context, Functor &&slot)

Diese Methode fügt dem Element „ QHttpServerRouter “ des Servers einen neuen Routing- Rule hinzu. Der Vorlagenparameter „ Rule “ kann eine beliebige Klasse sein, die von „ QHttpServerRouterRule “ abgeleitet ist. Die Parameter werden an „ Rule “ übergeben. Der Server gleicht eingehende HTTP-Anfragen anhand des URL-Pfads und der HTTP-Methode mit den registrierten Regeln ab, und die erste Übereinstimmung beider Kriterien wird ausgeführt.

Der Parameter „ pathPattern “ wird mit dem Wert von ` path()` der URL der eingehenden Anfrage verglichen. Der Parameter „ method “ wird mit der HTTP-Methode der eingehenden Anfrage verglichen. Der Parameter „ slot “ ist der Request-Handler. Er kann ein Zeiger auf eine Mitgliedsfunktion von „ context “, ein Funktionszeiger, ein nicht veränderbliches Lambda oder ein beliebiges kopierbares Aufrufobjekt mit einem const-Aufrufoperator sein. Wenn „ context “ angegeben wird, bleibt die Regel gültig, solange der Kontext existiert. „ context “ muss dieselbe Thread-Affinität wie „ QHttpServer “ aufweisen.

Der „ slot “ nimmt als Argumente eine beliebige Anzahl von geparsten Argumenten entgegen, die aus dem „ pathPattern “ durch Abgleich mit den Platzhaltern „ "<arg>" “ extrahiert werden, gefolgt von einem optionalen „ QHttpServerRequest “ und einem optionalen „ QHttpServerResponder “. Diese beiden Klassen werden als „Specials“ bezeichnet.

Die Funktion „ slot “ kann einen „ QHttpServerResponse “ oder einen konvertierbaren Typ zurückgeben:

QHttpServer server;
server.route("/test/", this, [] () { return ""; });

Alternativ muss, wenn ein optionales Argument vom Typ „ QHttpServerResponder “ übergeben wird, die Antwort unter Verwendung dieses Arguments geschrieben werden, und die Funktion muss „ void “ oder „ QFuture<void>“ zurückgeben. „ QFuture “ Die Unterstützung für <VOID> wurde in Qt 6.11 hinzugefügt. Die ` QHttpServerResponder ` ist nicht kopierbar und kann als Referenz oder R-Wert-Referenz übergeben werden, außer bei der Rückgabe eines ` QFuture` <VOID>; in diesem Fall muss sie als R-Wert-Referenz übergeben werden, um zu verhindern, dass sie den Gültigkeitsbereich verlässt.

server.route("/test2", this,
             [] (QHttpServerResponder &&responder) {
                responder.write(QHttpServerResponder::StatusCode::Forbidden);
             });

Darüber hinaus kann ` QHttpServerRequest ` als letztes Argument oder – falls ein ` QHttpServerResponder `-Argument vorhanden ist – als vorletztes Argument verwendet werden, um detaillierte Informationen zur Anfrage abzurufen. Es kann als `const`-Referenz (nur für nicht-parallele Callbacks) oder per Wert übergeben werden und dient dem Zugriff auf den Hauptteil der Anfrage:

server.route("/test3", QHttpServerRequest::Method::Post, this,
             [] (QHttpServerRequest request, QHttpServerResponder &&responder) {
                responder.write(request.body(), "text/plain"_ba);
             });

Jeder Platzhalter ( "<arg>" ) in „ pathPattern “ wird automatisch so konvertiert, dass er mit den Argumenttypen des Handlers übereinstimmt. Zu den unterstützten Typen gehören Ganzzahlen, Gleitkommazahlen, „ QString “, „ QByteArray “ und „ QUrl “. Die Klasse „ QUrl “ kann als letzter Parameter verwendet werden, um das Ende von „ pathPattern “ zu verarbeiten, und durch Aufteilen kann eine beliebige Anzahl von Argumenten unterstützt werden. Benutzerdefinierte Konverter können mit „ QHttpServerRouter::addConverter()“ hinzugefügt werden.

Jedem registrierten Typ ist ein regulärer Ausdruck zugeordnet, der zum Abgleichen und Konvertieren von Platzhaltern in pathPattern verwendet wird. Diese regulären Ausdrücke werden kombiniert, um einen Parser für den gesamten Pfad zu erstellen. Der resultierende Parser wird dann verwendet, um zu überprüfen, ob der Pfad mit dem Muster übereinstimmt. Gelingt die Analyse, wird die entsprechende Funktion mit den konvertierten Parametern aufgerufen. Schlägt die Analyse fehl, wird der nächste registrierte Callback versucht. Schlägt die Analyse für alle Callbacks fehl, wird der `missingHandler` aufgerufen.

Im folgenden Beispiel wird der Wert im Anfragepfad, der „ "<arg>" “ ersetzt, in „ int “ umgewandelt, da das Lambda-Ausdruck einen Parameter vom Typ „ int “ erwartet. Wenn eine HTTP-Anfrage mit der Route übereinstimmt, wird der umgewandelte Wert an das Argument „ page “ des Lambda-Ausdrucks übergeben:

QHttpServer server;
server.route("/showpage/<arg>", this, [] (int page) { return getPage(page); });

Diese Funktion gibt bei Erfolg einen Zeiger auf die neu erstellte „Rule“ zurück, andernfalls ein „ nullptr “. Der Zeiger kann verwendet werden, um Parameter in einer beliebigen benutzerdefinierten „ QHttpServerRouter “-Klasse zu setzen:

auto rule = server.route<MyRule>("/test4", this, [] () {return "";});
rule->setParameter("test");

Anfragen werden standardmäßig sequenziell im Thread des ` QHttpServer` verarbeitet. Der Request-Handler kann ` QFuture<QHttpServerResponse> ` zurückgeben, wenn eine parallele Verarbeitung gewünscht ist:

server.route("/feature/<arg>", [] (int ms) {
    return QtConcurrent::run(pool, [ms] () {
        QThread::msleep(ms);
        return QHttpServerResponse("the future is coming");
    });
});

Das Lambda von `QtConcurrent::run()` wird parallel ausgeführt, doch die gesamte Netzwerkkommunikation erfolgt in dem Thread, zu dem die ` QHttpServer ` gehört.

Routen, die Futures zurückgeben, werden nur über eine HTTP/2-Verbindung vollständig parallel ausgeführt. Frühere HTTP-Versionen unterstützen keine Verschachtelung von Teilen verschiedener Antworten: Die Antworten müssen vollständig und in derselben Reihenfolge zurückkommen, in der die Anfragen eingegangen sind. Selbst wenn ein Routen-Handler also ein ` QFuture<void>` zurückgibt, wird die nächste eingehende Anfrage auf dieser HTTP/1-Verbindung erst verarbeitet, wenn die Verarbeitung der aktuellen Anfrage abgeschlossen ist. Routen-Handler auf verschiedenen Verbindungen können jedoch parallel ausgeführt werden.

Die parallele Ausführung eines Routenhandlers kann für alle HTTP-Versionen Vorteile bieten, da der Thread, zu dem ` QHttpServer ` gehört, von der Arbeit entlastet wird, die die parallele Ausführung übernimmt.

QHttpServerRequest ist kopierbar und muss bei der Rückgabe eines Futures als Wert erfasst werden, da die an ` slot ` übergebenen Variablen möglicherweise aus dem Gültigkeitsbereich herausfallen, bevor der Future abgeschlossen ist.

server.route("/test4", QHttpServerRequest::Method::Post, this,
             [] (QHttpServerRequest request) {
                return QtConcurrent::run(pool, [request]() {
                    return QHttpServerResponse("text/plain"_ba, request.body());
                }
             });

Ein ` slot `, der bei der Rückgabe eines Futures ` QHttpServerRequest ` oder ` QHttpServerResponder ` per Referenz erfasst, löst eine Assertion mit einer Erklärung aus, warum dies verboten ist.

Da nicht alle Plattformen die Übertragung von ` QHttpServerResponder ` in ein veränderbliches Lambda unterstützen, das an `QConcurrent::run` übergeben wird, besteht die Umgehungslösung darin, ` QHttpServerResponder ` in einen `std::shared_ptr` zu verschieben und diesen zu kopieren.

server.route("/concurrent-multipart-back/<arg>",
             [](QString message, QHttpServerResponder &&responder) {
                return QtConcurrent::run(pool,
                    [=, r = std::make_shared<QHttpServerResponder>(std::move(responder))] {
                        QByteArray ba = message.toUtf8();
                        r->writeBeginChunked("text/plain"_ba);
                        for (ushort i = 1; i < 8; ++i) {
                            r->writeChunk(ba);
                        }
                        r->writeEndChunked(ba);
                    });
            });

Siehe auch „ QHttpServerRouter::addRule “ und „ addAfterRequestHandler “.

template <typename Rule = QHttpServerRouterRule, typename Functor> Rule *QHttpServer::route(const QString &pathPattern, Functor &&handler)

Überladung von ` QHttpServer::route `, um eine Regel für ` pathPattern ` und ` QHttpServerRequest::Method::AnyKnown` zu erstellen. Alle Anfragen werden an ` handler` weitergeleitet, wobei es sich um einen Funktionszeiger, ein unveränderliches Lambda oder ein beliebiges anderes kopierbares Aufrufobjekt mit dem `const call`-Operator handeln kann. Die Regel bleibt gültig, bis ` QHttpServer ` zerstört wird.

template <typename Rule = QHttpServerRouterRule, typename Functor> Rule *QHttpServer::route(const QString &pathPattern, QHttpServerRequest::Methods method, Functor &&handler)

Überladung von ` QHttpServer::route `, um eine Regel für ` pathPattern ` und ` method` zu erstellen. Alle Anfragen werden an ` handler` weitergeleitet, bei dem es sich um einen Funktionszeiger, ein unveränderliches Lambda oder ein beliebiges anderes kopierbares aufrufbares Objekt mit dem `const call`-Operator handeln kann. Die Regel gilt, bis das ` QHttpServer ` zerstört wird.

template <typename Rule = QHttpServerRouterRule, typename Functor> Rule *QHttpServer::route(const QString &pathPattern, const QObject *context, Functor &&slot)

Überladung von „ QHttpServer::route “, um eine Regel für „ pathPattern “ und die Methode „ QHttpServerRequest::Method::AnyKnown “ zu erstellen. Alle Anfragen werden an „ context “ und „ slot “ weitergeleitet.

QHttpServerRouter *QHttpServer::router()

Gibt einen Zeiger auf das Router-Objekt zurück.

const QHttpServerRouter *QHttpServer::router() const

Gibt einen Zeiger auf das konstante Router-Objekt zurück.

template <typename Functor> void QHttpServer::setMissingHandler(const QObject *context, Functor &&slot)

Legen Sie einen Handler für nicht verarbeitete Anfragen fest.

Alle nicht verarbeiteten Anfragen werden an die Methode „ slot “ des „ context “ weitergeleitet.

Der „ slot “ muss die Signatur „ void (*)(const QHttpServerRequest &, QHttpServerResponder &) “ implementieren. Der „ slot “ kann auch ein Funktionszeiger, ein nicht veränderbliches Lambda oder ein beliebiges anderes kopierbares Aufrufobjekt mit dem const-Aufrufoperator sein. In diesem Fall ist der „ context “ ein Kontextobjekt. Der Handler ist gültig, bis das Kontextobjekt zerstört wird.

Der Standard-Handler antwortet mit dem Status „ 404 Not Found “.

Siehe auch „ clearMissingHandler “.