QWebEngineUrlRequestJob Class

Dokumentation der Mitgliedsfunktionen

void QWebEngineUrlRequestJob::fail(QWebEngineUrlRequestJob::Error r)

Scheitert die Anfrage mit dem Fehler r.

Siehe auch Error.

QUrl QWebEngineUrlRequestJob::initiator() const

Gibt den serialisierten Ursprung des Inhalts zurück, der die Anfrage ausgelöst hat.

Im Allgemeinen besteht der Ursprung aus einem Schema, einem Hostnamen und einem Port. Zum Beispiel wäre "http://localhost:8080" ein gültiger Ursprung. Der Port wird weggelassen, wenn es sich um den Standardport des Schemas handelt (80 für http, 443 für https). Der Hostname wird weggelassen, wenn es sich nicht um ein Netzwerk handelt, wie file und qrc.

Es gibt jedoch auch den speziellen Wert "null", der für einen eindeutigen Ursprung steht. Dies ist z. B. der Ursprung eines Sandbox-iframe. Der Zweck dieses speziellen Ursprungs ist es, sich immer von allen anderen Ursprüngen bei der Prüfung des gleichen Ursprungs zu unterscheiden. Mit anderen Worten: Inhalte mit einem eindeutigen Ursprung sollten niemals privilegierten Zugang zu anderen Inhalten haben.

Wurde die Anfrage nicht von Web-Inhalten initiiert, gibt die Funktion einen leeren QUrl zurück. Dies geschieht zum Beispiel beim Aufruf von QWebEnginePage::setUrl().

Dieser Wert kann für die Implementierung sicherer herkunftsübergreifender Prüfungen verwendet werden.

void QWebEngineUrlRequestJob::redirect(const QUrl &url)

Leitet die Anfrage an url weiter.

void QWebEngineUrlRequestJob::reply(const QByteArray &contentType, QIODevice *device)

Antwortet auf die Anfrage mit device und dem Inhaltstyp contentType. Der Inhaltstyp ähnelt dem HTTP-Content-Type-Header und kann entweder ein MIME-Typ oder eine Kombination aus MIME-Typ und Zeichensatzkodierung wie folgt sein: "text/html; charset=utf-8".

Der Benutzer muss sich bewusst sein, dass device auf einem anderen Thread verwendet wird, bis der Auftrag gelöscht wird. Falls ein gleichzeitiger Zugriff vom Haupt-Thread aus erwünscht ist, liegt es in der Verantwortung des Benutzers, den Zugriff auf device thread-sicher zu machen, z. B. durch Verwendung von QMutex. Beachten Sie, dass das Objekt device nicht im Besitz der Web-Engine ist. Daher muss das Signal QObject::destroyed() von QWebEngineUrlRequestJob überwacht werden.

Das Gerät sollte mindestens so lange verfügbar bleiben, wie der Auftrag existiert. Wenn diese Methode mit einem neu erstellten Gerät aufgerufen wird, besteht eine Lösung darin, das Gerät als Kind des Auftrags zu erstellen oder sich selbst zu löschen, wenn der Auftrag gelöscht wird, etwa so:

connect(job, &QObject::destroyed, device, &QObject::deleteLater);

[since 6.7] QIODevice *QWebEngineUrlRequestJob::requestBody() const

Gibt einen Zeiger auf eine QIODevice zurück, die den Zugriff auf den Request Body ermöglicht. Der Request Body kann Daten enthalten, wenn es sich beispielsweise um eine POST-Anfrage handelt. Wenn der Request Body leer ist, reflektiert QIODevice dies und gibt keine Daten zurück, wenn Leseoperationen darauf ausgeführt werden.

Diese Funktion wurde in Qt 6.7 eingeführt.

Siehe auch QIODevice.

QMap<QByteArray, QByteArray> QWebEngineUrlRequestJob::requestHeaders() const

Gibt alle HTTP-Header zurück, die der Anfrage hinzugefügt wurden.

QByteArray QWebEngineUrlRequestJob::requestMethod() const

Gibt die HTTP-Methode der Anfrage zurück (z. B. GET oder POST).

QUrl QWebEngineUrlRequestJob::requestUrl() const

Gibt die angeforderte URL zurück.

[since 6.6] void QWebEngineUrlRequestJob::setAdditionalResponseHeaders(const QMultiMap<QByteArray, QByteArray> &additionalResponseHeaders) const

Setzen Sie additionalResponseHeaders. Diese zusätzlichen Kopfzeilen der Antwort werden nur verwendet, wenn QWebEngineUrlRequestJob::reply(const QByteArray&, QIODevice*) aufgerufen wird.

Diese Funktion wurde in Qt 6.6 eingeführt.