(use-modules (web request))
The request module contains a data type for HTTP requests.
HTTP requests consist of two parts: the request proper, consisting of a request line and a set of headers, and (optionally) a body. The body might have a binary content-type, and even in the textual case its length is specified in bytes, not characters.
Therefore, HTTP is a fundamentally binary protocol. However the request line and headers are specified to be in a subset of ASCII, so they can be treated as text, provided that the port’s encoding is set to an ASCII-compatible one-byte-per-character encoding. ISO-8859-1 (latin-1) is just such an encoding, and happens to be very efficient for Guile.
So what Guile does when reading requests from the wire, or writing them out, is to set the port’s encoding to latin-1, and treating the request headers as text.
The request body is another issue. For binary data, the data is probably in a bytevector, so we use the R6RS binary output procedures to write out the binary payload. Textual data usually has to be written out to some character encoding, usually UTF-8, and then the resulting bytevector is written out to the port.
In summary, Guile reads and writes HTTP over latin-1 sockets, without any loss of generality.
A predicate and field accessors for the request type. The fields are as follows:
method
The HTTP method, for example, GET
.
uri
The URI as a URI record.
version
The HTTP version pair, like (1 . 1)
.
headers
The request headers, as an alist of parsed values.
meta
An arbitrary alist of other data, for example information returned in
the sockaddr
from accept
(see Network Sockets and Communication).
port
The port on which to read or write a request body, if any.
Read an HTTP request from port, optionally attaching the given metadata, meta.
As a side effect, sets the encoding on port to ISO-8859-1 (latin-1), so that reading one character reads one byte. See the discussion of character sets above, for more information.
Note that the body is not part of the request. Once you have read a request, you may read the body separately, and likewise for writing requests.
Construct an HTTP request object. If validate-headers? is true, the headers are each run through their respective validators.
Write the given HTTP request to port.
Return a new request, whose request-port
will continue writing
on port, perhaps using some transfer encoding.
Reads the request body from r, as a bytevector. Return #f
if there was no request body.
Write bv, a bytevector, to the port corresponding to the HTTP request r.
The various headers that are typically associated with HTTP requests may be accessed with these dedicated accessors. See HTTP Headers, for more information on the format of parsed headers.
Return the given request header, or default if none was present.
A helper routine to determine the absolute URI of a request, using the
host
header and the default scheme, host and port. If there is
no default scheme and the URI is not itself absolute, an error is
signaled.