- 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
- 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.2 library(http/http_dispatch): Dispatch requests in the HTTP server
Most code doesn't need to use this directly; instead use
library(http/http_server)
, which combines this library with
the typical HTTP libraries that most servers need.
This module can be placed between http_wrapper.pl
and
the application code to associate HTTP locations to predicates
that serve the pages. In addition, it associates parameters with
locations that deal with timeout handling and user authentication. The
typical setup is:
server(Port, Options) :- http_server(http_dispatch, [ port(Port) | Options ]). :- http_handler('/index.html', write_index, []). write_index(Request) :- ...
- [det]http_handler(+Path, :Closure, +Options)
- Register Closure as a handler for HTTP requests. Path
is either an absolute path such as
'/home.html'
or a term Alias(Relative). Where Alias is associated with a concrete path using http:location/3 and resolved using http_absolute_location/3. Relative can be a single atom or a term‘Segment1/Segment2/...`, where each element is either an atom or a variable. If a segment is a variable it matches any segment and the binding may be passed to the closure. If the last segment is a variable it may match multiple segments. This allows registering REST paths, for example::- http_handler(root(user/User), user(Method, User), [ method(Method), methods([get,post,put]) ]). user(get, User, Request) :- ... user(post, User, Request) :- ...
If an HTTP request arrives at the server that matches Path, Closure is called as below, where Request is the parsed HTTP request.
call(Closure, Request)
Options is a list containing the following options:
- authentication(+Type)
- Demand authentication. Authentication methods are pluggable. The library
http_authenticate.pl
provides a plugin for user/password basedBasic
HTTP authentication. - chunked
- Use
Transfer-encoding: chunked
if the client allows for it. - condition(:Goal)
- If present, the handler is ignored if Goal does not succeed.
- content_type(+Term)
- Specifies the content-type of the reply. This value is currently not used by this library. It enhances the reflexive capabilities of this library through http_current_handler/3.
- id(+Atom)
- Identifier of the handler. The default identifier is the predicate name. Used by http_location_by_id/2 and http_link_to_id/3.
- hide_children(+Bool)
- If
true
on a prefix-handler (see prefix), possible children are masked. This can be used to (temporary) overrule part of the tree. - method(+Method)
- Declare that the handler processes Method. This is equivalent
to
methods([Method])
. Usingmethod(*)
allows for all methods. - methods(+ListOfMethods)
- Declare that the handler processes all of the given methods. If this option appears multiple times, the methods are combined.
- prefix
- Call Pred on any location that is a specialisation of Path.
If multiple handlers match, the one with the longest path is used.
Options defined with a prefix handler are the default options
for paths that start with this prefix. Note that the handler acts as a
fallback handler for the tree below it:
:- http_handler(/, http_404([index('index.html')]), [spawn(my_pool),prefix]).
- priority(+Integer)
- If two handlers handle the same path, the one with the highest priority is used. If equal, the last registered is used. Please be aware that the order of clauses in multifile predicates can change due to reloading files. The default priority is 0 (zero).
- spawn(+SpawnOptions)
- Run the handler in a separate thread. If SpawnOptions is an atom, it is interpreted as a thread pool name (see create_thread_pool/3). Otherwise the options are passed to http_spawn/2 and from there to thread_create/3. These options are typically used to set the stack limits.
- time_limit(+Spec)
- One of
infinite
,default
or a positive number (seconds). Ifdefault
, the value from the settinghttp:time_limit
is taken. The default of this setting is 300 (5 minutes). See setting/2.
Note that http_handler/3 is normally invoked as a directive and processed using term-expansion. Using term-expansion ensures proper update through make/0 when the specification is modified.
- Errors
- -
existence_error(http_location, Location)
-permission_error(http_method, Method, Location)
- See also
- http_reply_file/3 and http_redirect/3 are generic handlers to serve files and achieve redirects.
- [det]http_delete_handler(+Spec)
- Delete handler for Spec. Typically, this should only be used
for handlers that are registered dynamically. Spec is one of:
- id(Id)
- Delete a handler with the given id. The default id is the handler-predicate-name.
- path(Path)
- Delete handler that serves the given path.
- [det]http_dispatch(Request)
- Dispatch a Request using http_handler/3
registrations. It performs the following steps:
- Find a matching handler based on the
path
member of Request. If multiple handlers match due to theprefix
option or variables in path segments (see http_handler/3), the longest specification is used. If multiple specifications of equal length match the one with the highest priority is used. - Check that the handler matches the
method
member of the Request or throwpermission_error(http_method, Method, Location)
- Expand the request using expansion hooks registered by
http_request_expansion/3. This may add
fields to the request, such the authenticated user, parsed parameters,
etc. The hooks may also throw exceptions, notably using http_redirect/3
or by throwing
http_reply(Term, ExtraHeader, Context)
exceptions. - Extract possible fields from the Request using e.g.
method(Method)
as one of the options. - Call the registered closure, optionally spawning the request to a new thread or enforcing a time limit.
- Find a matching handler based on the
- http_request_expansion(:Goal, +Rank:number)
- Register Goal for expanding the HTTP request handler. Goal
is called as below. If Goal fail the request is passed to the
next expansion unmodified.
call(Goal, Request0, Request, Options)
If multiple goals are registered they expand the request in a pipeline starting with the expansion hook with the lowest rank.
Besides rewriting the request, for example by validating the user identity based on HTTP authentication or cookies and adding this to the request, the hook may raise HTTP exceptions to indicate a bad request, permission error, etc. See http_status_reply/4.
Initially, auth_expansion/3 is registered with rank
100
to deal with the older http:authenticate/3 hook. - [semidet]http_current_handler(+Location, :Closure)
- [nondet]http_current_handler(-Location, :Closure)
- True if Location is handled by Closure.
- [semidet]http_current_handler(+Location, :Closure, -Options)
- [nondet]http_current_handler(?Location, :Closure, ?Options)
- Resolve the current handler and options to execute it.
- [det]http_location_by_id(+ID, -Location)
- True when Location represents the HTTP path to which the
handler with identifier ID is bound. Handler identifiers are
deduced from the http_handler/3
declaration as follows:
- Explicit id
- If a term
id(ID)
appears in the option list of the handler, ID it is used and takes preference over using the predicate. - Using the handler predicate
- ID matches a handler if the predicate name matches ID.
The
ID may have a module qualification, e.g.,
Module:Pred
If the handler is declared with a pattern, e.g.,
root(user/User)
, the location to access a particular user may be accessed using e.g.,user('Bob')
. The number of arguments to the compound term must match the number of variables in the path pattern.A plain atom ID can be used to find a handler with a pattern. The returned location is the path up to the first variable, e.g.,
/user/
in the example above.User code is adviced to use http_link_to_id/3 which can also add query parameters to the URL. This predicate is a helper for http_link_to_id/3.
- Errors
existence_error(http_handler_id, Id)
.- See also
- http_link_to_id/3 and the
library(http/html_write)
constructlocation_by_id(ID)
or its abbreviation#(ID)
- http_link_to_id(+HandleID, +Parameters, -HREF)
- HREF is a link on the local server to a handler with given
ID, passing the given Parameters. This predicate is typically
used to formulate a HREF that resolves to a handler
implementing a particular predicate. The code below provides a typical
example. The predicate user_details/1
returns a page with details about a user from a given id. This predicate
is registered as a handler. The DCG user_link//1
renders a link to a user, displaying the name and calling user_details/1
when clicked. Note that the location (
root(user_details)
) is irrelevant in this equation and HTTP locations can thus be moved freely without breaking this code fragment.:- http_handler(root(user_details), user_details, []). user_details(Request) :- http_parameters(Request, [ user_id(ID) ]), ... user_link(ID) --> { user_name(ID, Name), http_link_to_id(user_details, [id(ID)], HREF) }, html(a([class(user), href(HREF)], Name)).
HandleID is either an atom, possibly module qualified predicate or a compound term if the hander is defined using a pattern. See http_handler/3 and http_location_by_id/2. Parameters is one of path_postfix(File)
to pass a single value as the last segment of the HTTP location (path). This way of passing a parameter is commonly used in REST APIs.New code should use a path pattern in the handler declaration and a term‘HandleID(Arg, ...)`
- A list of search parameters for a
GET
request.
- See also
- http_location_by_id/2 and http_handler/3 for defining and specifying handler IDs.
- [det]http_reload_with_parameters(+Request, +Parameters, -HREF)
- Create a request on the current handler with replaced search parameters.
- [det]http_reply_file(+FileSpec, +Options, +Request)
- Options is a list of
- cache(+Boolean)
- If
true
(default), handle If-modified-since and send modification time. - mime_type(+Type)
- Overrule mime-type guessing from the filename as provided by file_mime_type/2.
- static_gzip(+Boolean)
- If true (default
false
) and, in addition to the plain file, there is a.gz
file that is not older than the plain file and the client accepsgzip
encoding, send the compressed file withTransfer-encoding: gzip
. - unsafe(+Boolean)
- If
false
(default), validate that FileSpec does not contain references to parent directories. E.g., specifications such aswww('../../etc/passwd')
are not allowed. - headers(+List)
- Provides additional reply-header fields, encoded as a list of Field(Value).
If caching is not disabled, it processes the request headers
If-modified-since
andRange
.- throws
- -
http_reply(not_modified)
-http_reply(file(MimeType, Path))
- [det]http_safe_file(+FileSpec, +Options)
- True if FileSpec is considered safe. If it is an atom,
it cannot be absolute and cannot have references to parent directories.
If it is of the form
alias(Sub)
, than Sub cannot have references to parent directories.- Errors
- - instantiation_error
-permission_error(read, file, FileSpec)
- [det]http_redirect(+How, +To, +Request)
- Redirect to a new location. The argument order, using the
Request as last argument, allows for calling this directly
from the handler declaration:
:- http_handler(root(.), http_redirect(moved, myapp('index.html')), []).
How is one of moved
,moved_temporary
orsee_other
To is an atom, a aliased path as defined by http_absolute_location/3. or a term location_by_id(Id)
or its abbreviations#(Id)
or#(Id)+Parameters
. If To is not absolute, it is resolved relative to the current location. - [det]http_404(+Options, +Request)
- Reply using an "HTTP 404 not found" page. This handler is intended as
fallback handler for prefix handlers. Options
processed are:
- index(Location)
- If there is no path-info, redirect the request to Location using http_redirect/3.
- Errors
http_reply(not_found(Path))
- http_switch_protocol(:Goal, +Options)
- Send an
"HTTP 101 Switching Protocols"
reply. After sending the reply, the HTTP library callscall(Goal, InStream, OutStream)
, where InStream and OutStream are the raw streams to the HTTP client. This allows the communication to continue using an an alternative protocol.If Goal fails or throws an exception, the streams are closed by the server. Otherwise Goal is responsible for closing the streams. Note that Goal runs in the HTTP handler thread. Typically, the handler should be registered using the
spawn
option if http_handler/3 or Goal must call thread_create/3 to allow the HTTP worker to return to the worker pool.The streams use binary (octet) encoding and have their I/O timeout set to the server timeout (default 60 seconds). The predicate set_stream/2 can be used to change the encoding, change or cancel the timeout.
This predicate interacts with the server library by throwing an exception.
The following options are supported:
- header(+Headers)
- Backward compatible. Use
headers(+Headers)
. - headers(+Headers)
- Additional headers send with the reply. Each header takes the form Name(Value).