qhttp.3qt

Linux下的基于X11的图形开发环境。

'\" t
.TH QHttp 3qt "9 December 2002" "Trolltech AS" \" -*- nroff -*-
.\" Copyright 1992-2001 Trolltech AS.  All rights reserved.  See the
.\" license file included in the distribution for a complete license
.\" statement.
.\"
.ad l
.nh
.SH NAME
QHttp \- Implementation of the HTTP protocol
.SH SYNOPSIS
\fC#include <qhttp.h>\fR
.PP
Inherits QNetworkProtocol.
.PP
.SS "Public Members"
.in +1c
.ti -1c
.BI "\fBQHttp\fR ()"
.br
.ti -1c
.BI "\fBQHttp\fR ( QObject * parent, const char * name = 0 )"
.br
.ti -1c
.BI "\fBQHttp\fR ( const QString & hostname, Q_UINT16 port = 80, QObject * parent = 0, const char * name = 0 )"
.br
.ti -1c
.BI "virtual \fB~QHttp\fR ()"
.br
.ti -1c
.BI "enum \fBState\fR { Unconnected, HostLookup, Connecting, Sending, Reading, Connected, Closing }"
.br
.ti -1c
.BI "enum \fBError\fR { NoError, UnknownError, HostNotFound, ConnectionRefused, UnexpectedClose, InvalidResponseHeader, WrongContentLength, Aborted }"
.br
.ti -1c
.BI "int \fBsetHost\fR ( const QString & hostname, Q_UINT16 port = 80 )"
.br
.ti -1c
.BI "int \fBget\fR ( const QString & path, QIODevice * to = 0 )"
.br
.ti -1c
.BI "int \fBpost\fR ( const QString & path, QIODevice * data, QIODevice * to = 0 )"
.br
.ti -1c
.BI "int \fBpost\fR ( const QString & path, const QByteArray & data, QIODevice * to = 0 )"
.br
.ti -1c
.BI "int \fBhead\fR ( const QString & path )"
.br
.ti -1c
.BI "int \fBrequest\fR ( const QHttpRequestHeader & header, QIODevice * data = 0, QIODevice * to = 0 )"
.br
.ti -1c
.BI "int \fBrequest\fR ( const QHttpRequestHeader & header, const QByteArray & data, QIODevice * to = 0 )"
.br
.ti -1c
.BI "int \fBcloseConnection\fR ()"
.br
.ti -1c
.BI "Q_ULONG \fBbytesAvailable\fR () const"
.br
.ti -1c
.BI "Q_LONG \fBreadBlock\fR ( char * data, Q_ULONG maxlen )"
.br
.ti -1c
.BI "QByteArray \fBreadAll\fR ()"
.br
.ti -1c
.BI "int \fBcurrentId\fR () const"
.br
.ti -1c
.BI "QIODevice * \fBcurrentSourceDevice\fR () const"
.br
.ti -1c
.BI "QIODevice * \fBcurrentDestinationDevice\fR () const"
.br
.ti -1c
.BI "QHttpRequestHeader \fBcurrentRequest\fR () const"
.br
.ti -1c
.BI "bool \fBhasPendingRequests\fR () const"
.br
.ti -1c
.BI "void \fBclearPendingRequests\fR ()"
.br
.ti -1c
.BI "State \fBstate\fR () const"
.br
.ti -1c
.BI "Error \fBerror\fR () const"
.br
.ti -1c
.BI "QString \fBerrorString\fR () const"
.br
.in -1c
.SS "Public Slots"
.in +1c
.ti -1c
.BI "void \fBabort\fR ()"
.br
.in -1c
.SS "Signals"
.in +1c
.ti -1c
.BI "void \fBstateChanged\fR ( int state )"
.br
.ti -1c
.BI "void \fBresponseHeaderReceived\fR ( const QHttpResponseHeader & resp )"
.br
.ti -1c
.BI "void \fBreadyRead\fR ( const QHttpResponseHeader & resp )"
.br
.ti -1c
.BI "void \fBdataSendProgress\fR ( int done, int total )"
.br
.ti -1c
.BI "void \fBdataReadProgress\fR ( int done, int total )"
.br
.ti -1c
.BI "void \fBrequestStarted\fR ( int id )"
.br
.ti -1c
.BI "void \fBrequestFinished\fR ( int id, bool error )"
.br
.ti -1c
.BI "void \fBdone\fR ( bool error )"
.br
.in -1c
.SH DESCRIPTION
The QHttp class provides an implementation of the HTTP protocol.
.PP
This class provides two different interfaces: one is the QNetworkProtocol interface that allows you to use HTTP through the QUrlOperator abstraction. The other is a direct interface to HTTP that allows you to have more control over the requests and that allows you to access the response header fields.
.PP
Don't mix the two interfaces, since the behavior is not well-defined.
.PP
If you want to use QHttp with the QNetworkProtocol interface, you do not use it directly, but rather through a QUrlOperator, for example:
.PP
.nf
.br
    QUrlOperator op( "http://www.trolltech.com" );
.br
    op.get( "index.html" );
.br
.fi
.PP
This code will only work if the QHttp class is registered; to register the class, you must call qInitNetworkProtocols() before using a QUrlOperator with HTTP.
.PP
The QNetworkProtocol interface for HTTP only supports the operations operationGet() and operationPut(), i.e. QUrlOperator::get() and QUrlOperator::put(), if you use it with a QUrlOperator.
.PP
The rest of this descrption describes the direct interface to HTTP.
.PP
The class works asynchronously, so there are no blocking functions. If an operation cannot be executed immediately, the function will still return straight away and the operation will be scheduled for later execution. The results of scheduled operations are reported via signals. This approach depends on the event loop being in operation.
.PP
The operations that can be scheduled (they are called "requests" in the rest of the documentation) are the following: setHost(), get(), post(), head() and request().
.PP
All of these requests return a unique identifier that allows you to keep track of the request that is currently executed. When the execution of a request starts, the requestStarted() signal with the identifier is emitted and when the request is finished, the requestFinished() signal is emitted with the identifier and a bool that indicates if the request finished with an error.
.PP
To make an HTTP request you must set up suitable HTTP headers. The following example demonstrates, how to request the main HTML page from the Trolltech home page (i.e. the URL http://www.trolltech.com/index.html):
.PP
.nf
.br
    QHttpRequestHeader header( "GET", "/index.html" );
.br
    header.setValue( "Host", "www.trolltech.com" );
.br
    http->setHost( "www.trolltech.com" );
.br
    http->request( header );
.br
.fi
.PP
For the common HTTP requests \fCGET\fR, \fCPOST\fR and \fCHEAD\fR, QHttp provides the convenience functions get(), post() and head(). They already use a reasonable header and if you don't have to set special header fields, they are easier to use. The above example can also be written as:
.PP
.nf
.br
    http->setHost( "www.trolltech.com" ); // id == 1
.br
    http->get( "/index.html" );           // id == 2
.br
.fi
.PP
For this example the following sequence of signals is emitted (with small variations, depending on network traffic, etc.):
.PP
.nf
.br
    requestStarted( 1 )
.br
    requestFinished( 1, FALSE )
.br
.br
    requestStarted( 2 )
.br
    stateChanged( Connecting )
.br
    stateChanged( Sending )
.br
    dataSendProgress( 77, 77 )
.br
    stateChanged( Reading )
.br
    responseHeaderReceived( responseheader )
.br
    dataReadProgress( 5388, 0 )
.br
    readyRead( responseheader )
.br
    dataReadProgress( 18300, 0 )
.br
    readyRead( responseheader )
.br
    stateChanged( Connected )
.br
    requestFinished( 2, FALSE )
.br
.br
    done( FALSE )
.br
.br
    stateChanged( Closing )
.br
    stateChanged( Unconnected )
.br
.fi
.PP
The dataSendProgress() and dataReadProgress() signals in the above example are useful if you want to show a progressbar to inform the user about the progress of the download. The second argument is the total size of data. In certain cases it is not possible to know the total amount in advance, in which case the second argument is 0. (If you connect to a QProgressBar a total of 0 results in a busy indicator.)
.PP
When the response header is read, it is reported with the responseHeaderReceived() signal.
.PP
The readyRead() signal tells you that there is data ready to be read. The amount of data can then be queried with the bytesAvailable() function and it can be read with the readBlock() or readAll() functions.
.PP
If an error occurs during the execution of one of the commands in a sequence of commands, all the pending commands (i.e. scheduled, but not yet executed commands) are cleared and no signals are emitted for them.
.PP
For example, if you have the following sequence of reqeusts
.PP
.nf
.br
    http->setHost( "www.foo.bar" );       // id == 1
.br
    http->get( "/index.html" );           // id == 2
.br
    http->post( "register.html", data );  // id == 3
.br
.fi
.PP
and the get() request fails because the host lookup fails, then the post() request is never executed and the signals would look like this:
.PP
.nf
.br
    requestStarted( 1 )
.br
    requestFinished( 1, FALSE )
.br
.br
    requestStarted( 2 )
.br
    stateChanged( HostLookup )
.br
    requestFinished( 2, TRUE )
.br
.br
    done( TRUE )
.br
.br
    stateChanged( Unconnected )
.br
.fi
.PP
You can then get details about the error with the error() and errorString() functions. Note that only unexpected behaviour, like network failure is considered as an error. If the server response contains an error status, like a 404 response, this is reported as a normal response case. So you should always check the status code of the response header.
.PP
The functions currentId() and currentRequest() provide more information about the currently executing request.
.PP