- Documentation
- Reference manual
- Packages
- SWI-Prolog HTTP support
- The HTTP server libraries
- Creating an HTTP reply
- library(http/http_dispatch): Dispatch requests in the HTTP server
- library(http/http_dirindex): HTTP directory listings
- library(http/http_files): Serve plain files from a hierarchy
- library(http/http_session): HTTP Session management
- library(http/http_cors): Enable CORS: Cross-Origin Resource Sharing
- library(http/http_authenticate): Authenticate HTTP connections using 401 headers
- library(http/http_digest): HTTP Digest authentication
- library(http/http_dyn_workers): Dynamically schedule HTTP workers.
- Custom Error Pages
- library(http/http_openid): OpenID consumer and server library
- Get parameters from HTML forms
- Request format
- Running the server
- The wrapper library
- library(http/http_host): Obtain public server location
- library(http/http_log): HTTP Logging module
- library(http/http_server_health): HTTP Server health statistics
- Debugging HTTP servers
- library(http/http_header): Handling HTTP headers
- The library(http/html_write) library
- library(http/js_write): Utilities for including JavaScript
- library(http/http_path): Abstract specification of HTTP server locations
- library(http/html_head): Automatic inclusion of CSS and scripts links
- library(http/http_pwp): Serve PWP pages through the HTTP server
- The HTTP server libraries
- SWI-Prolog HTTP support
3.13 Request format
The body-code (see section 3.1) is
driven by a Request. This request is generated from http_read_request/2
defined in
library(http/http_header)
.
- http_read_request(+Stream, -Request)
- Reads an HTTP request from Stream and unify Request
with the parsed request. Request is a list of
Name(Value)
elements. It provides a number of predefined elements for the result of parsing the first line of the request, followed by the additional request parameters. The predefined fields are:- host(Host)
- If the request contains
Host:
Host, Host is unified with the host-name. If Host is of the format <host>:<port> Host only describes <host> and a fieldport(Port)
where Port is an integer is added. - input(Stream)
- The Stream is passed along, allowing to read more data or requests from the same stream. This field is always present.
- method(Method)
- Method is the HTTP method represented as a
lower-case atom (i.e.,
delete
,get
,head
,options
,patch
,post
,put
,trace
). This field is present if the header has been parsed successfully. - path(Path)
- Path associated to the request. This field is always present.
- peer(Peer)
- Peer is a term
ip(A,B,C,D)
containing the IP address of the contacting host. - port(Port)
- Port requested. See
host
for details. - request_uri(RequestURI)
- This is the untranslated string that follows the method in the request header. It is used to construct the path and search fields of the Request. It is provided because reconstructing this string from the path and search fields may yield a different value due to different usage of percent encoding.
- search(ListOfNameValue)
- Search-specification of URI. This is the part after the
, normally used to transfer data from HTML forms that use the HTTP GET method. In the URL it consists of a www-form-encoded list of Name=Value pairs. This is mapped to a list of Prolog Name=Value terms with decoded names and values. This field is only present if the location contains a search-specification.?
The URL specification does not demand the query part to be of the form name=value. If the field is syntactically incorrect, ListOfNameValue is bound the the empty list ([]).
- http_version(Major-Minor)
- If the first line contains the
HTTP/
Major.Minor version indicator this element indicate the HTTP version of the peer. Otherwise this field is not present. - cookie(ListOfNameValue)
- If the header contains a
Cookie
line, the value of the cookie is broken down in Name=Value pairs, where the Name is the lowercase version of the cookie name as used for the HTTP fields. - set_cookie(set_cookie(Name, Value, Options))
- If the header contains a
SetCookie
line, the cookie field is broken down into the Name of the cookie, the Value and a list of Name=Value pairs for additional options such asexpire
,path
,domain
orsecure
.
If the first line of the request is tagged with
HTTP/
Major.Minor, http_read_request/2 reads all input upto the first blank line. This header consists of Name:Value fields. Each such field appears as a termName(Value)
in the Request, where Name is canonicalised for use with Prolog. Canonisation implies that the Name is converted to lower case and all occurrences of the
are replaced by-
_
. The value for theContent-length
fields is translated into an integer.
Here is an example:
?- http_read_request(user_input, X). |: GET /mydb?class=person HTTP/1.0 |: Host: gollem |: X = [ input(user), method(get), search([ class = person ]), path('/mydb'), http_version(1-0), host(gollem) ].
3.13.1 Handling POST requests
Where the HTTP GET
operation is intended to get a
document, using a path and possibly some additional search
information, the POST
operation is intended to hand
potentially large amounts of data to the server for processing.
The Request parameter above contains the term method(post)
.
The data posted is left on the input stream that is available through
the term input(Stream)
from the Request header.
This data can be read using http_read_data/3
from the HTTP client library. Here is a demo implementation simply
returning the parsed posted data as plain text (assuming pp/1
pretty-prints the data).
reply(Request) :- member(method(post), Request), !, http_read_data(Request, Data, []), format('Content-type: text/plain~n~n', []), pp(Data).
If the POST is initiated from a browser, content-type is generally
either application/x-www-form-urlencoded
or
multipart/form-data
.