Class Server

java.lang.Object
All Implemented Interfaces:
Proxy

@Generated("io.github.jwharm.JavaGI") public class Server extends GObject
A HTTP server.

SoupServer implements a simple HTTP server.

To begin, create a server using Server(java.lang.String, java.lang.Object...). Add at least one handler by calling addHandler(java.lang.String, org.gnome.soup.ServerCallback) or addEarlyHandler(java.lang.String, org.gnome.soup.ServerCallback); 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 SoupServer will emit Server::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 ServerMessage signals.

Once the headers have been read, SoupServer will check if there is a AuthDomain (qv) covering the Request-URI; if so, and if the message does not contain suitable authorization, then the AuthDomain will set a status of Status.UNAUTHORIZED on the message.

After checking for authorization, SoupServer will look for "early" handlers (added with addEarlyHandler(java.lang.String, org.gnome.soup.ServerCallback)) 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 SoupServer will skip the remaining steps and return the response. If the request headers contain Expect: 100-continue and no status code has been set, SoupServer will return a 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 Status.NOT_FOUND to the client.

Otherwise (assuming no previous step assigned a status to the message) any "normal" handlers (added with addHandler(java.lang.String, org.gnome.soup.ServerCallback)) 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), SoupServer will attempt to validate the WebSocket handshake, filling in the response and setting a status of Status.SWITCHING_PROTOCOLS or Status.BAD_REQUEST accordingly.

If the message still has no status code at this point (and has not been paused with ServerMessage.pause()), then it will be given a status of Status.INTERNAL_SERVER_ERROR (because at least one handler ran, but returned without assigning a status).

Finally, the server will emit Server::request-finished (or Server::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 Server:tls-certificate property.

Once the server is set up, make one or more calls to listen(org.gnome.gio.SocketAddress, java.util.Set<org.gnome.soup.ServerListenOptions>), listenLocal(int, java.util.Set<org.gnome.soup.ServerListenOptions>), or listenAll(int, java.util.Set<org.gnome.soup.ServerListenOptions>) to tell it where to listen for connections. (All ports on a SoupServer 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 SoupServers, or else check the passed-in URI in the handler function.).

SoupServer will begin processing connections as soon as you return to (or start) the main loop for the current thread-default GLib.MainContext.