QHttpServer Class

Documentation des fonctions membres

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

Crée une instance de QHttpServer avec le parent parent.

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

Détruit un QHttpServer.

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

Enregistrez un context et un slot qui seront appelés après le traitement de chaque demande.

Le slot doit implémenter la signature void (*)(const QHttpServerRequest &, QHttpServerResponse &).

Le slot peut également être un pointeur de fonction, un lambda non modifiable ou tout autre objet copiable avec l'opérateur const call. Dans ce cas, context sera un objet contextuel et le gestionnaire sera valide jusqu'à ce que l'objet contextuel soit détruit.

Exemple :

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()

Réinitialise le gestionnaire à celui par défaut qui produit des réponses avec le statut 404 Not Found.

Voir aussi setMissingHandler.

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

Cette méthode ajoute un nouveau routage Rule au membre QHttpServerRouter du serveur. Le paramètre de modèle Rule peut être n'importe quelle classe dérivée de QHttpServerRouterRule. Les paramètres sont transmis à Rule. Le serveur compare les requêtes HTTP entrantes aux règles enregistrées basées sur le chemin d'accès à l'URL et la méthode HTTP, et la première de ces deux correspondances est exécutée.

Le paramètre pathPattern est comparé à path() de l'URL de la requête entrante. Le paramètre method est comparé à la méthode HTTP de la requête entrante. Le paramètre slot est le gestionnaire de la demande. Il peut s'agir d'un pointeur de fonction membre de context, d'un pointeur de fonction, d'un lambda non modifiable ou de tout élément copiable avec un opérateur d'appel const. Si context est fourni, la règle reste valable tant que le contexte existe. Le context doit partager la même affinité thread que le QHttpServer.

slot prend comme arguments un nombre quelconque d'arguments analysés, qui sont extraits de pathPattern en faisant correspondre les espaces réservés de "<arg>", suivis d'un QHttpServerRequest et d'un QHttpServerResponder facultatifs. Ces deux classes sont appelées "specials".

Le slot peut renvoyer un QHttpServerResponse ou un type convertible :

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

Par ailleurs, si un argument optionnel QHttpServerResponder est fourni, la réponse doit être écrite en l'utilisant et la fonction doit renvoyer void ou QFuture<void>. La prise en charge de QFuture<void> a été ajoutée dans la version 6.11 de Qt. Le QHttpServerResponder n'est pas copiable et peut être transmis en tant que référence ou référence rvalue, sauf lorsqu'il renvoie un QFuture<void>, auquel cas il doit être transmis en tant que référence rvalue pour éviter qu'il ne sorte de son champ d'application.

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

En outre, QHttpServerRequest peut être utilisé comme dernier argument ou, s'il existe un argument QHttpServerResponder, comme avant-dernier argument pour obtenir des informations détaillées sur la demande. Il peut être transmis en tant que référence constante (uniquement pour les rappels non simultanés) ou par valeur, et peut être utilisé pour accéder au corps de la demande :

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

Tout espace réservé ( "<arg>" ) dans pathPattern est automatiquement converti pour correspondre aux types d'arguments du gestionnaire. Les types pris en charge sont les suivants : entiers, nombres à virgule flottante, QString, QByteArray et QUrl. La classe QUrl peut être utilisée comme dernier paramètre pour gérer la fin de pathPattern, et en la divisant, un nombre arbitraire d'arguments peut être pris en charge. Des convertisseurs personnalisés peuvent être ajoutés en utilisant QHttpServerRouter::addConverter().

Chaque type enregistré est associé à une expression rationnelle qui est utilisée pour faire correspondre et convertir les caractères génériques dans pathPattern. Ces expressions rationnelles sont combinées pour construire un analyseur syntaxique pour l'ensemble du chemin. L'analyseur résultant est ensuite utilisé pour vérifier si le chemin correspond au motif. Si l'analyse réussit, la fonction correspondante est appelée avec les paramètres convertis. En cas d'échec de l'analyse, le rappel enregistré suivant est tenté. Si l'analyse échoue pour tous les rappels, le gestionnaire manquant (missingHandler) est appelé.

Dans l'exemple ci-dessous, la valeur du chemin de requête remplaçant "<arg>" est convertie en int car la fonction lambda attend un paramètre int. Lorsqu'une requête HTTP correspond à l'itinéraire, la valeur convertie est transmise à l'argument page de la lambda :

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

Cette fonction renvoie, en cas de succès, un pointeur sur la règle nouvellement créée, sinon un nullptr. Le pointeur peut être utilisé pour définir des paramètres sur n'importe quelle classe QHttpServerRouter personnalisée :

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

Par défaut, les demandes sont traitées de manière séquentielle dans le fil d'exécution de QHttpServer. Le gestionnaire de requêtes peut renvoyer QFuture<QHttpServerResponse> si un traitement simultané est souhaité :

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

La lambda de QtConcurrent::run() est exécutée simultanément, mais toutes les communications réseau sont exécutées dans le thread auquel appartient QHttpServer.

Les routes renvoyant des futures ne sont exécutées de manière totalement concurrente que sur une connexion HTTP/2. Les versions antérieures de HTTP ne prennent pas en charge l'entrelacement de parties de différentes réponses : Les réponses doivent être renvoyées dans leur intégralité et dans le même ordre que les demandes. Ainsi, même si un gestionnaire d'itinéraires renvoie une réponse QFuture<void>, la prochaine demande entrant sur cette connexion HTTP/1 ne sera pas traitée tant que le traitement de la demande en cours ne sera pas terminé. Les gestionnaires d'itinéraires situés sur des connexions différentes peuvent être exécutés simultanément.

Faire en sorte qu'un gestionnaire de route effectue son travail dans le cadre d'une exécution concurrente peut présenter des avantages pour toutes les versions de HTTP, car le thread auquel appartient QHttpServer sera déchargé du travail effectué par l'exécution concurrente.

QHttpServerRequest est copiable et doit être capturé par valeur lorsqu'il renvoie un futur, car les variables passées à slot peuvent sortir du champ d'application avant que le futur ne soit terminé.

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

Un slot qui capture QHttpServerRequest ou QHttpServerResponder par référence lors du retour d'un futur provoque une assertion avec une explication sur la raison de l'interdiction.

Toutes les plateformes ne supportent pas le déplacement de QHttpServerResponder dans un lambda mutable qui est passé à QConcurrent::run, donc le contournement est de déplacer QHttpServerResponder dans un std::shared_ptr et de le copier.

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);
                    });
            });

Voir aussi QHttpServerRouter::addRule et addAfterRequestHandler.

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

Surcharge de QHttpServer::route pour créer une règle pour pathPattern et QHttpServerRequest::Method::AnyKnown. Toutes les demandes sont transmises à handler, qui peut être un pointeur de fonction, un lambda non modifiable ou tout autre objet copiable avec l'opérateur const call. La règle sera valide jusqu'à ce que QHttpServer soit détruit.

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

Surcharge de QHttpServer::route pour créer une règle pour pathPattern et method. Toutes les demandes sont transmises à handler, qui peut être un pointeur de fonction, un lambda non modifiable ou tout autre objet copiable avec l'opérateur const call. La règle sera valide jusqu'à ce que QHttpServer soit détruit.

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

Surcharge de QHttpServer::route pour créer une règle pour pathPattern et la méthode QHttpServerRequest::Method::AnyKnown. Toutes les demandes sont transmises à context et slot.

QHttpServerRouter *QHttpServer::router()

Renvoie un pointeur sur l'objet routeur.

const QHttpServerRouter *QHttpServer::router() const

Renvoie un pointeur sur l'objet routeur constant.

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

Définir un gestionnaire pour les demandes non traitées.

Toutes les demandes non gérées seront transmises à l'adresse context's slot.

Le slot doit implémenter la signature void (*)(const QHttpServerRequest &, QHttpServerResponder &). L'adresse slot peut également être un pointeur de fonction, un lambda non modifiable ou tout autre objet copiable avec l'opérateur const call. Dans ce cas, context sera un objet contextuel. Le gestionnaire sera valide jusqu'à ce que l'objet contextuel soit détruit.

Le gestionnaire par défaut répond avec le statut 404 Not Found.

Voir aussi clearMissingHandler.