14.3.5.Beyond Basics

All output from VSP page procedures is buffered into a local string stream before being sent out. This is done so as to support the HTTP/1.1 required content length and to allow recovery from errors.

http_rewrite ( in stream any);

This clears any previous output to the stream. If the stream is omitted or 0 the stream is the HTTP client stream of the calling procedure.

http_file ( in path varchar);

This function sends a file to the HTTP client as a response to the current request. Any other output that may have been generated by the calling procedure will be discarded and the contents of the file will be the exclusive response to the current HTTP request together with appropriate headers. The file will only be sent after the procedure handling the current HTTP request has returned. The file name is thus not validated until the calling procedure has returned.

http_get( in uri varchar, out headers varchar);

This function retrieves the document specified by the URI by HTTP and returns the data of the response. The header output parameter is set to be an array with an element for each line of the response's HTTP header. Each line is a varchar object in the containing array. The header parameter is optional.

The URI is of the form host[:port]<path> , e.g 'www.openlinksw.com:80/index.html '. The port, if omitted, defaults to 80. The data following the headers is not processed in any way. No content transfer encodings are decoded but an eventual content transfer encoding header can be found in the header array.

http_flush();

This function generates a response header, flushes a stream and disconnects the client, however, the server will continue with the execution of the PL code in VSP page. The final result will never be sent to the client. This is useful when a page makes a long transaction and we do not wish the client to wait until its end, which may result in a time-out. Suppose we have the retrieval of news from many targets, each a thousand messages. We start from a VSP page process, inside it we put into the internal stream (using http, http_value etc.) redirect code and call http_flush. The client can read the response and go to a status page that can display number of messages retrieved, which may need refreshing a few times.

http_proxy (in host_and_port varchar, in header_lines any, in post_parameters any)

The function http_proxy() is used to send request in header_lines and post_parameters to the host_and_port, read the response and send it back to the client. The http_proxy() function can be used inside a VSP page to send a request to an external web server and automatically route the reply sent by this remote server to the client of the VSP page calling http_proxy(). The output which can generated (with http functions, etc.) before and after http_proxy is called will be discarded before sending the result of link retrieval to the user-agent.

Example14.10.Virtuoso Proxy

...
<?vsp
  http ('this never be displayed');
  http_proxy ('www.foo.com', vector ('GET / HTTP/1.0'), NULL);
  http ('and this also');
?>
...

Virtuoso HTTP Server Character Set Settings

When the HTTP server returns the HTTP header to the client it appends charset=xxxx to the Content-Type: HTTP header fields. This informs the client user agent, the web browser, as to the character set of the content to be displayed correctly. It uses the Web server charset to correctly format values resulting from the http_value() function or the VSP equivalent <?= ...>. Wide values and XML entities, resulting from any XML processing functions like xpath_contains, get represented using the "HTML/XML transformation".

The default web server charset is governed by the Charset setting defined in the Virtuoso INI file . If no default charset is specified then Virtuoso will use ISO-8859-1.

The HTTP character set can be changed during an HTTP session using: set http_charset='charset_name'; .

The XSLT output encoding can also be specified to over ride the server default setting.

Session Management and State Variables

The Virtuoso HTTP session management consists of functions for session variables manipulation and hooks for saving and restoring session variables.

Session management must be enable by setting the flag for persistent session variables in the virtual directory mapping. Virtual directory mappings use the persistent_session_variables flag, which when specified, session variables can be used in a post-process function to determine if the session variables content must be stored on to the session table or not.

The post-processing function hook can be any user-defined Virtuoso/PL procedure, it will be executed every time after processing of the active page.