3 The HTTP server libraries
AllApplicationManualNameSummaryHelp

  • 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
            • http_wrapper/5
            • request_expansion/2
            • http_current_request/1
            • http_relative_path/2
          • 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

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 or close 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.