- 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.15 The wrapper library
The body is called by the module library(http/http_wrapper.pl)
.
This module realises the communication between the I/O streams and the
body described in section 3.1. The
interface is realised by
http_wrapper/5:
- http_wrapper(:Goal, +In, +Out, -Connection, +Options)
- Handle an HTTP request where In is an input stream from the
client, Out is an output stream to the client and Goal
defines the goal realising the body. Connection is unified to
’Keep-alive'
if both ends of the connection want to continue the connection orclose
if either side wishes to close the connection.This predicate reads an HTTP request-header from In, redirects current output to a memory file and then runs
call(Goal, Request)
, watching for exceptions and failure. If Goal executes successfully it generates a complete reply from the created output. Otherwise it generates an HTTP server error with additional context information derived from the exception.http_wrapper/5 supports the following options:
- request(-Request)
- Return the executed request to the caller.
- peer(+Peer)
- Add peer(Peer) to the request header handed to Goal. The format of Peer is defined by tcp_accept/3 from the clib package.
- http:request_expansion(+RequestIn, -RequestOut)
- This multifile hook predicate is called just before the goal
that produces the body, while the output is already redirected to
collect the reply. If it succeeds it must return a valid modified
request. It is allowed to throw exceptions as defined in
section 3.1.1. It is intended for
operations such as mapping paths, deny access for certain requests or
manage cookies. If it writes output, these must be HTTP header fields
that are added before header fields written by the body. The
example below is from the session management library (see section
3.5) sets a cookie.
..., format('Set-Cookie: ~w=~w; path=~w~n', [Cookie, SessionID, Path]), ...,
- http_current_request(-Request)
- Get access to the currently executing request. Request is the same as handed to Goal of http_wrapper/5 after applying rewrite rules as defined by http:request_expansion/2. Raises an existence error if there is no request in progress.
- http_relative_path(+AbsPath, -RelPath)
- Convert an absolute path (without host, fragment or search) into a path
relative to the current page, defined as the path component from the
current request (see http_current_request/1).
This call is intended to create reusable components returning relative
paths for easier support of reverse proxies.
If ---for whatever reason--- the conversion is not possible it simply unifies RelPath to AbsPath.