view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        is assumed to be / in these examples.

         $Response->Cookies('name', 'value'); 
          --> Set-Cookie: name=value; path=/

         $Response->Cookies("Test", "data1", "test value");     
         $Response->Cookies("Test", "data2", "more test");      
         $Response->Cookies(
                "Test", "Expires", 
                &HTTP::Date::time2str(time+86400)
                ); 
         $Response->Cookies("Test", "Secure", 1);               
         $Response->Cookies("Test", "Path", "/");
         $Response->Cookies("Test", "Domain", "host.com");
          -->   Set-Cookie:Test=data1=test%20value&data2=more%20test;   \
                        expires=Fri, 23 Apr 1999 07:19:52 GMT;          \
                        path=/; domain=host.com; secure

        The latter use of $key in the cookies not only sets cookie attributes
        such as Expires, but also treats the cookie as a hash of key value pairs
        which can later be accesses by

         $Request->Cookies('Test', 'data1');
         $Request->Cookies('Test', 'data2');

        Because this is perl, you can (NOT PORTABLE) reference the cookies
        directly through hash notation. The same 5 commands above could be
        compressed to:

         $Response->{Cookies}{Test} = 
                { 
                        Secure  => 1, 
                        Value   =>      
                                {
                                        data1 => 'test value', 
                                        data2 => 'more test'
                                },
                        Expires => 86400, # not portable, see above
                        Domain  => 'host.com',
                        Path    => '/'
                };

        and the first command would be:

         # you don't need to use hash notation when you are only setting 
         # a simple value
         $Response->{Cookies}{'Test Name'} = 'Test Value';

        I prefer the hash notation for cookies, as this looks nice, and is quite
        perlish. It is here to stay. The Cookie() routine is very complex and
        does its best to allow access to the underlying hash structure of the
        data. This is the best emulation I could write trying to match the
        Collections functionality of cookies in IIS ASP.

        For more information on Cookies, please go to the source at
        http://home.netscape.com/newsref/std/cookie_spec.html

    $Response->Debug(@args)
        API Extension. If the Debug config option is set greater than 0, this
        routine will write @args out to server error log. refs in @args will be
        expanded one level deep, so data in simple data structures like
        one-level hash refs and array refs will be displayed. CODE refs like

         $Response->Debug(sub { "some value" });

        will be executed and their output added to the debug output. This
        extension allows the user to tie directly into the debugging
        capabilities of this module.

        While developing an app on a production server, it is often useful to
        have a separate error log for the application to catch debugging output
        separately. One way of implementing this is to use the Apache ErrorLog
        configuration directive to create a separate error log for a virtual
        host.

        If you want further debugging support, like stack traces in your code,
        consider doing things like:

         $Response->Debug( sub { Carp::longmess('debug trace') };
         $SIG{__WARN__} = \&Carp::cluck; # then warn() will stack trace

        The only way at present to see exactly where in your script an error
        occurred is to set the Debug config directive to 2, and match the error
        line number to perl script generated from your ASP script.

        However, as of version 0.10, the perl script generated from the asp
        script should match almost exactly line by line, except in cases of
        inlined includes, which add to the text of the original script, pod
        comments which are entirely yanked out, and <% # comment %> style
        comments which have a \n added to them so they still work.

        If you would like to see the HTML preceding an error while developing,
        consider setting the BufferingOn config directive to 0.

    $Response->End()
        Sends result to client, and immediately exits script. Automatically
        called at end of script, if not already called.

    $Response->ErrorDocument($code, $uri)
        API extension that allows for the modification the Apache ErrorDocument
        at runtime. $uri may be a on site document, off site URL, or string
        containing the error message.

        This extension is useful if you want to have scripts set error codes
        with $Response->{Status} like 401 for authentication failure, and to
        then control from the script what the error message looks like.

        For more information on the Apache ErrorDocument mechanism, please see
        ErrorDocument in the CORE Apache settings, and the
        Apache->custom_response() API, for which this method is a wrapper.

    $Response->Flush()
        Sends buffered output to client and clears buffer.

    $Response->Include($filename, @args)
        This API extension calls the routine compiled from asp script in
        $filename with the args @args. This is a direct translation of the SSI
        tag

          <!--#include file=$filename args=@args-->