• Places
    • Home
    • Graphs
    • Prefixes
  • Admin
    • Users
    • Settings
    • Plugins
    • Statistics
  • Repository
    • Load local file
    • Load from HTTP
    • Load from library
    • Remove triples
    • Clear repository
  • Query
    • YASGUI SPARQL Editor
    • Simple Form
  • Help
    • Documentation
    • Tutorial
    • Roadmap
    • HTTP Services
  • Login

3 The HTTP server libraries
AllApplicationManualNameSummaryHelp

  • Documentation
    • Reference manual
    • Packages
      • SWI-Prolog HTTP support
        • The HTTP server libraries
          • The `Body'
            • Returning special status codes
          • 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
          • 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

3.1 The `Body'

The server-body is the code that handles the request and formulates a reply. To facilitate all mentioned setups, the body is driven by http_wrapper/5. The goal is called with the parsed request (see section 3.12) as argument and current_output set to a temporary buffer. Its task is closely related to the task of a CGI script; it must write a header declaring holding at least the Content-type field and a body. Here is a simple body writing the request as an HTML table.

reply(Request) :-
        format('Content-type: text/html~n~n', []),
        format('<html>~n', []),
        format('<table border=1>~n'),
        print_request(Request),
        format('~n</table>~n'),
        format('</html>~n', []).

print_request([]).
print_request([H|T]) :-
        H =.. [Name, Value],
        format('<tr><td>~w<td>~w~n', [Name, Value]),
        print_request(T).

The infrastructure recognises the header fields described below. Other header lines are passed verbatim to the client. Typical examples are Set-Cookie and authentication headers (see section 3.7).

Content-type: Type
This field is passed to the client and used by the infrastructure to determine the encoding to use for the stream. If type matches text/* or the type matches with UTF-8 (case insensitive), the server uses UTF-8 encoding. The user may force UTF-8 encoding for arbitrary content types by adding ; charset=UTF-8 to the end of the Content-type header.
Transfer-encoding: chunked
Causes the server to use chunked encoding if the client allows for it. See also section 4 and the chunked option in http_handler/3.
Connection: close
Causes the connection to be closed after the transfer. The default is to keep it open `Keep-Alive' if possible.
Location: URL
This header may be combined with the Status header to force a redirect response to the given URL. The message body must be empty. Handling this header is primarily intended for compatibility with the CGI conventions. Prolog code should use http_redirect/3.
Status: Status
This header can be combined with Location, where Status must be one of 301 (moved), 302 (moved temporary, default) or 303 (see other).

3.1.1 Returning special status codes

Besides returning a page by writing it to the current output stream, the server goal can raise an exception using throw/1 to generate special pages such as not_found, moved, etc. The defined exceptions are:

http_reply(+Reply, +HdrExtra)
Return a result page using http_reply/3. See http_reply/3 for details.
http_reply(+Reply)
Equivalent to http_reply(Reply,[]).
http(not_modified)
Equivalent to http_reply(not_modified,[]). This exception is for backward compatibility and can be used by the server to indicate the referenced resource has not been modified since it was requested last time.

In addition, the normal "200 OK" reply status may be overruled by writing a CGI Status header prior to the remainder of the message. This is particularly useful for defining REST APIs. The following handler replies with a "201 Created" header:

handle_request(Request) :-
        process_data(Request, Id),      % application predicate
        format('Status: 201~n'),
        format('Content-type: text/plain~n~n'),
        format('Created object as ~q~n', [Id]).

ClioPatria (version V3.0.0-338-gc91dba5-DIRTY)