/ 
Continuity-1.6
River stage one • 4 direct dependents • 4 total dependents
/ Continuity::Adapt::HttpDaemon

NAME

Continuity::Adapt::HttpDaemon - Use HTTP::Daemon to get HTTP requests

Continuity::Adapt::HttpDaemon::Request - an HTTP::Daemon based request

DESCRIPTION

This is the default and reference HTTP adapter for Continuity. The only thing a normal user of Continuity would want to do with this is in the new method, all the rest is for internal use. See Continuity::Request for the general request API used by an application.

An adapter interfaces between the continuation server (Continuity) and the web server (HTTP::Daemon, FastCGI, etc). It provides incoming HTTP requests to the continuation server. It comes in two parts, the server connector and the request interface.

This adapter interfaces with HTTP::Daemon.

This module was designed to be subclassed to fine-tune behavior.

METHODS

$adapter = Continuity::Adapt::HttpDaemon->new(...)

Create a new continuation adapter and HTTP::Daemon. This actually starts the HTTP server, which is embeded. It takes the same arguments as the HTTP::Daemon module, and those arguments are passed along. It also takes the optional argument docroot => '/path'. This adapter may then be specified for use with the following code:

my $server = Contuinity->new(adapter => $adapter);

This method is required for all adapters.

$adapter->get_request()

Map a URL path to a filesystem path

Called in a loop from Contuinity.

Returns the empty list on failure, which aborts the server process. Aside from the constructor, this is the heart of this module.

This method is required for all adapters.

$adapter->map_path($path)

Decodes URL-encoding in the path and attempts to guard against malice. Returns the processed filesystem path.

$adapter->send_static($request)

Sends a static file off of the filesystem. The content-type is guessed by HTTP::Daemon, plus we specifically tell it how to do png, css, and js.

This may be obvious, but you can't send binary data as part of the same request that you've already sent text or HTML on, MIME aside. Thus either this is called OR we invoke a continuation, but not both.

See Continuity::Request for API documentation.

This is what gets passed through a queue to coroutines when new requests for them come in. It needs to encapsulate:

* The connection filehandle * CGI parameters cache

XXX todo: understands GET parameters and POST in application/x-www-form-urlencoded format, but not POST data in multipart/form-data format. Use the AsCGI thing if you actually really need that (it's used for file uploads). # XXX check request content-type, if it isn't x-form-data then throw an error # XXX pass in multiple param names, get back multiple param values

Delegates requests off to the request object it was initialized from.

In other words: Continuity::Adapt::HttpDaemon is the ongoing running HttpDaemon process, and Continuity::Adapt::HttpDaemon::Request is individual requests sent through.

HTTP::Daemon Overrides

Although HTTP::Daemon is lovely, we have to patch it a bit to work correctly with Coro. Fortunately there are only two things that much be touched, the 'accept' method and the _needs_more_data in HTTP::Daemon::ClientConn.

What we are doing is making these non-blocking using Coro::Event.

SEE ALSO

Continuity

AUTHOR

Brock Wilcox <awwaiid@thelackthereof.org> - http://thelackthereof.org/
Scott Walters <scott@slowass.net> - http://slowass.net/

COPYRIGHT

Copyright (c) 2004-2014 Brock Wilcox <awwaiid@thelackthereof.org>. All rights
reserved.  This program is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.