Server


Object Hierarchy:

Soup.Server Soup.Server Soup.Server GLib.Object GLib.Object GLib.Object->Soup.Server

Description:

[ CCode ( type_id = "soup_server_get_type ()" ) ]
public class Server : Object

A HTTP server.

Server implements a simple HTTP server.

To begin, create a server using [[email protected]]. Add at least one handler by calling [[email protected]_handler] or [ [email protected]_early_handler]; the handler will be called to process any requests underneath the path you pass. (If you want all requests to go to the same handler, just pass "/" (or null) for the path.)

When a new connection is accepted (or a new request is started on an existing persistent connection), the Server will emit [signal@Server:SoupServer:request-started] and then begin processing the request as described below, but note that once the message is assigned a status-code, then callbacks after that point will be skipped. Note also that it is not defined when the callbacks happen relative to various [class@ServerMessage] signals.

Once the headers have been read, Server will check if there is a [class@AuthDomain] `(qv)` covering the Request-URI; if so, and if the message does not contain suitable authorization, then the [class@AuthDomain] will set a status of soup_status_unauthorized on the message.

After checking for authorization, Server will look for "early" handlers (added with [ [email protected]_early_handler]) matching the Request-URI. If one is found, it will be run; in particular, this can be used to connect to signals to do a streaming read of the request body.

(At this point, if the request headers contain `Expect: 100-continue`, and a status code has been set, then Server will skip the remaining steps and return the response. If the request headers contain `Expect: 100-continue` and no status code has been set, Server will return a soup_status_continue status before continuing.)

The server will then read in the response body (if present). At this point, if there are no handlers at all defined for the Request-URI, then the server will return soup_status_not_found to the client.

Otherwise (assuming no previous step assigned a status to the message) any "normal" handlers (added with [[email protected]_handler]) for the message's Request-URI will be run.

Then, if the path has a WebSocket handler registered (and has not yet been assigned a status), Server will attempt to validate the WebSocket handshake, filling in the response and setting a status of soup_status_switching_protocols or soup_status_bad_request accordingly.

If the message still has no status code at this point (and has not been paused with [[email protected]_message]), then it will be given a status of soup_status_internal_server_error (because at least one handler ran, but returned without assigning a status).

Finally, the server will emit [signal@Server:SoupServer:request-finished] (or [signal@Server: SoupServer:request-aborted] if an I/O error occurred before handling was completed).

If you want to handle the special "*" URI (eg, "OPTIONS *"), you must explicitly register a handler for "*"; the default handler will not be used for that case.

If you want to process https connections in addition to (or instead of) http connections, you can set the [ property@Server:tls-certificate] property.

Once the server is set up, make one or more calls to [[email protected]], [[email protected]_local], or [[email protected]_all] to tell it where to listen for connections. (All ports on a Server use the same handlers; if you need to handle some ports differently, such as returning different data for http and https, you'll need to create multiple `SoupServer`s, or else check the passed-in URI in the handler function.).

Server will begin processing connections as soon as you return to (or start) the main loop for the current thread-default [[email protected]].


Namespace: Soup
Package: libsoup-3.0

Content:

Properties:

Creation methods:

Methods:

Signals:

Inherited Members:

All known members inherited from class GLib.Object



2022 vala-language.org