Request

API

function
&key (request \*request\*)

Returns association list with GET or POST parameters for current request.

function
name &key (request \*request\*)

Returns GET or POST parameter by name.

function
name &key (request \*request\*)

Returns value of the HTTP header or nil. Name is case insensitive.

function
name &key (request \*request\*)

Returns value of the cookie or nil. Name is case insensitive string.

function
&key (request \*request\*)
function
&key (request \*request\*)

Detects if the current request was initiated via AJAX by looking for X-Requested-With http header. This function expects to be called in a dynamic hunchentoot environment.

function
&key (request \*request\*)
function
&key (request \*request\*)

Returns a webserver's port.

It may be not a port a lisp server listens on but a port a reverse proxy listens on.

function
&key (request \*request\*)

Returns association list with GET or POST parameters for current request.

Determines if a request is a result of the user invoking a browser refresh function. Note that a request will not be considered a refresh if there is an action involved (even if the user hits refresh).

function
name &key (request \*request\*)

Removes a HTTP header by name, returns new instance of request without given header.

function
&key (request \*request\*)

For URL http://example.com/foo/bar?blah=minor returns it as is.

function
&key (request \*request\*) with-params

For URL http://example.com/foo/bar?blah=minor returns /foo/bar path of the request's URL.

function
&key (request \*request\*)

Returns a possible user's IP.

Note, it may not be reliable, because user might try to set these headers manually.

This method handles each request as it comes in from the server. It is a hunchentoot handler and has access to all hunchentoot dynamic variables. The default implementation executes a user action (if any) and renders the root widget wrapped in HTML provided by 'render-page'. If the request is an AJAX request, only the dirty widgets are rendered into a JSON data structure. It also invokes user supplied 'reblocks/session:init' method on the first request that has no session setup.

'handle-request' immediately returns '+http-not-found+' if it sees a mime type on the script name (it doesn't handle what could be files because these mess with callback functions and break some widgets that depend on them).

Additionally, on the first request a session is created and a client is forced to redirect. At this point if the cookie is sent, session information is removed from the URL, otherwise the URL is left in tact. This is done so that session information appears on the URL for clients that don't support cookies (this way AJAX requests followed by a refresh will work).

This function also manages lists of callback functions and calls them at different points before and after request. See 'request-hook'.

Override this method (along with :before and :after specifiers) to customize behavior.

This generic function is called when Reblocks processes an action called from Javascript.

Seconds until we abort a request because it took too long. This prevents threads from hogging the CPU indefinitely.

You can set this to NIL to disable timeouts (not recommended).

This function is called when the current widget heirarchy fails to parse a URL. The default behavior simply sets the 404 return code

This macro binds current request and stores request path in the session if requiest is not AJAX.

Later, this value is used to determine if user refreshed the page.

Detects if the current request is declared as 'pure', i.e. affects no widgets or internal application state, but merely is a request for information.

Such requests simply return the result of the function that represents the action and are used by some AJAX operations to retreive information (suggest block, etc).

When such requests are satisfied, the actions have access to the session, the widgets, and all other parameters. However, none of the callbacks are executed, no widgets are sent to the client, etc.