This library combines the core server functionality provided by
several libraries that are needed by almost any web server. It exports
the commonly used predicates from library(http/thread_httpd),
library(http/http_dispatch), library(http/http_wrapper),
library(http/http_parameters), library(http/html_write),
library(http/http_json), and library(http/http_dyn_workers).
http_server(+Options) is det- Create an HTTP server using http_dispatch/1 for handling requests.
See http_server/2 and http_dispatch/1 for details.
Re-exported predicates
The following predicates are exported from this file while their implementation is defined in imported modules or non-module files loaded by this module.
html_meta +Heads is det- This directive can be used to declare that an HTML rendering
rule takes HTML content as argument. It has two effects. It
emits the appropriate meta_predicate/1 and instructs the
built-in editor (PceEmacs) to provide proper colouring for the
arguments. The arguments in Head are the same as for
meta_predicate or can be constant
html
. For example:
:- html_meta
page(html,html,?,?).
reply_html_page(:Head, :Body) is det
reply_html_page(+Style, :Head, :Body) is det- Provide the complete reply as required by http_wrapper.pl for a page
constructed from Head and Body. The HTTP
Content-type
is
provided by html_current_option/1.
- See also
- - reply_html_partial/1 to avoid adding a
DOCTYPE
, and
required outer HTML elements such as <html>
.
is_json_content_type(+ContentType) is semidet- True if ContentType is a header value (either parsed or as
atom/string) that denotes a JSON value.
http_read_json_dict(+Request, -Dict) is det
http_read_json_dict(+Request, -Dict, +Options) is det- Similar to http_read_json/2,3, but by default uses the version 7
extended datatypes.
http_read_json_dict(+Request, -Dict) is det
http_read_json_dict(+Request, -Dict, +Options) is det- Similar to http_read_json/2,3, but by default uses the version 7
extended datatypes.
reply_json_dict(+JSONTerm) is det
reply_json_dict(+JSONTerm, +Options) is det- As reply_json/1 and reply_json/2, but assumes the new dict based
data representation. Note that this is the default if the outer
object is a dict. This predicate is needed to serialize a list
of objects correctly and provides consistency with
http_read_json_dict/2 and friends.
reply_json_dict(+JSONTerm) is det
reply_json_dict(+JSONTerm, +Options) is det- As reply_json/1 and reply_json/2, but assumes the new dict based
data representation. Note that this is the default if the outer
object is a dict. This predicate is needed to serialize a list
of objects correctly and provides consistency with
http_read_json_dict/2 and friends.
http_parameters(+Request, ?Parms) is det
http_parameters(+Request, ?Parms, :Options) is det- Get HTTP GET or POST form-data, applying type validation,
default values, etc. Provided options are:
- attribute_declarations(:Goal)
- Causes the declarations for an attributed named A to be
fetched using
call(Goal, A, Declarations)
.
- form_data(-Data)
- Return the data read from the GET or POST request as a
list Name = Value. All data, including name/value pairs
used for Parms, is unified with Data.
The attribute_declarations hook allows sharing the declaration
of attribute-properties between many http_parameters/3 calls. In
this form, the requested attribute takes only one argument and
the options are acquired by calling the hook. For example:
...,
http_parameters(Request,
[ sex(Sex)
],
[ attribute_declarations(http_param)
]),
...
http_param(sex, [ oneof(male, female),
description('Sex of the person')
]).
- bug
- - If both request parameters (?name=value&...) and a POST are
present the parameters are extracted from the request parameters.
Still, as it is valid to have request parameters in a POST request
this predicate should not process POST requests. We will keep the
current behaviour as the it is not common for a request to have both
request parameters and a POST data of the type
application/x-www-form-urlencoded
.
In the unlikely event this poses a problem the request may be
specified as [method(get)
|Request].
http_parameters(+Request, ?Parms) is det
http_parameters(+Request, ?Parms, :Options) is det- Get HTTP GET or POST form-data, applying type validation,
default values, etc. Provided options are:
- attribute_declarations(:Goal)
- Causes the declarations for an attributed named A to be
fetched using
call(Goal, A, Declarations)
.
- form_data(-Data)
- Return the data read from the GET or POST request as a
list Name = Value. All data, including name/value pairs
used for Parms, is unified with Data.
The attribute_declarations hook allows sharing the declaration
of attribute-properties between many http_parameters/3 calls. In
this form, the requested attribute takes only one argument and
the options are acquired by calling the hook. For example:
...,
http_parameters(Request,
[ sex(Sex)
],
[ attribute_declarations(http_param)
]),
...
http_param(sex, [ oneof(male, female),
description('Sex of the person')
]).
- bug
- - If both request parameters (?name=value&...) and a POST are
present the parameters are extracted from the request parameters.
Still, as it is valid to have request parameters in a POST request
this predicate should not process POST requests. We will keep the
current behaviour as the it is not common for a request to have both
request parameters and a POST data of the type
application/x-www-form-urlencoded
.
In the unlikely event this poses a problem the request may be
specified as [method(get)
|Request].
http_current_request(-Request) is semidet- Returns the HTTP request currently being processed. Fails
silently if there is no current request. This typically happens
if a goal is run outside the HTTP server context.
http_peer(+Request, -PeerIP:atom) is semidet- True when PeerIP is the IP address of the connection peer. If the
connection is established via a proxy or CDN we try to find the
initiating peer. Currently supports:
Fastly-client-ip
X-real-ip
X-forwarded-for
- Direct connections
- bug
- - The
X-forwarded-for
header is problematic. According to
Wikipedia, the
original client is the first, while according to
AWS
it is the last.
http_server(:Goal, :Options) is det- Create a server at Port that calls Goal for each parsed request.
Options provide a list of options. Defined options are
- port(?Address)
- Port to bind to. Address is either a port or a term
Host:Port. The port may be a variable, causing the system
to select a free port. See tcp_bind/2.
- unix_socket(+Path)
- Instead of binding to a TCP port, bind to a Unix Domain
Socket at Path.
- entry_page(+URI)
- Affects the message printed while the server is started.
Interpreted as a URI relative to the server root.
- tcp_socket(+Socket)
- If provided, use this socket instead of the creating one and
binding it to an address. The socket must be bound to an
address. Note that this also allows binding an HTTP server to
a Unix domain socket (
AF_UNIX
). See socket_create/2.
- workers(+Count)
- Determine the number of worker threads. Default is 5. This
is fine for small scale usage. Public servers typically need
a higher number.
- timeout(+Seconds)
- Maximum time of inactivity trying to read the request after a
connection has been opened. Default is 60 seconds. See
set_stream/1 using the timeout option.
- keep_alive_timeout(+Seconds)
- Time to keep `Keep alive' connections alive. Default is
2 seconds.
- stack_limit(+Bytes)
- Stack limit to use for the workers. The default is inherited
from the
main
thread.
If you need to control resource usage you may consider the
spawn
option of http_handler/3 and library(thread_pool).
- silent(Bool)
- If
true
(default false
), do not print an informational
message that the server was started.
A typical initialization for an HTTP server that uses
http_dispatch/1 to relay requests to predicates is:
:- use_module(library(http/thread_httpd)).
:- use_module(library(http/http_dispatch)).
start_server(Port) :-
http_server(http_dispatch, [port(Port)]).
Note that multiple servers can coexist in the same Prolog
process. A notable application of this is to have both an HTTP
and HTTPS server, where the HTTP server redirects to the HTTPS
server for handling sensitive requests.
http_current_server(:Goal, ?Port) is nondet- True if Goal is the goal of a server at Port.
- deprecated
- - Use
http_server_property(Port, goal(Goal))
http_server_property(?Port, ?Property) is nondet- True if Property is a property of the HTTP server running at
Port. Defined properties are:
- goal(:Goal)
- Goal used to start the server. This is often
http_dispatch/1.
- scheme(-Scheme)
- Scheme is one of
http
or https
.
- start_time(?Time)
- Time-stamp when the server was created.
http_workers(?Port, -Workers) is nondet
- http_workers(+Port, +Workers:int) is det
- Query or set the number of workers for the server at this port. The
number of workers is dynamically modified. Setting it to 1 (one) can
be used to profile the worker using tprofile/1.
- See also
- - library(http/http_dyn_workers) implements dynamic management of
the worker pool depending on usage.
http_add_worker(+Port, +Options) is det- Add a new worker to the HTTP server for port Port. Options
overrule the default queue options. The following additional
options are processed:
- max_idle_time(+Seconds)
- The created worker will automatically terminate if there is
no new work within Seconds.
http_current_worker(?Port, ?ThreadID) is nondet- True if ThreadID is the identifier of a Prolog thread serving
Port. This predicate is motivated to allow for the use of
arbitrary interaction with the worker thread for development and
statistics.
http_stop_server(+Port, +Options)- Stop the indicated HTTP server gracefully. First stops all
workers, then stops the server.
- To be done
- - Realise non-graceful stop
http_spawn(:Goal, +Options) is det- Continue this connection on a new thread. A handler may call
http_spawn/2 to start a new thread that continues processing the
current request using Goal. The original thread returns to the
worker pool for processing new requests. Options are passed to
thread_create/3, except for:
- pool(+Pool)
- Interfaces to library(thread_pool), starting the thread
on the given pool.
If a pool does not exist, this predicate calls the multifile
hook create_pool/1 to create it. If this predicate succeeds
the operation is retried.
Undocumented predicates
The following predicates are exported, but not or incorrectly documented.
http_dispatch(Arg1)
http_reload_with_parameters(Arg1, Arg2, Arg3)
http_current_handler(Arg1, Arg2)
http_current_handler(Arg1, Arg2, Arg3)
http_redirect(Arg1, Arg2, Arg3)
http_404(Arg1, Arg2)
http_switch_protocol(Arg1, Arg2)
http_request_expansion(Arg1, Arg2)
http_link_to_id(Arg1, Arg2, Arg3)
http_reply_file(Arg1, Arg2, Arg3)
http_delete_handler(Arg1)
http_location_by_id(Arg1, Arg2)
http_handler(Arg1, Arg2, Arg3)
html(Arg1, Arg2, Arg3)