Apache2-POST200

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    hidden fields rather than saving them in a session structure at server
    side.

    Well, the database that this module uses is such a session structure at
    server side, but forget about the internals for now. Look at it from
    another level, ;-).

  Simpler developement
    "Apache2::POST200" frees your application from handling the refreshing
    problem by its own. Hence, developement becomes simpler.

  Performance
    Using "Apache2::POST200" might even lead to a performance gain. Often
    the application logic is almost the same (authentication, authorization,
    fetching application data and so on) be it for the generation of the
    Location header or for the redirected request. With this module these
    checks are done only once.

  Frontend / Backend
    Here comes the most valuable point. WEB applications often use a
    frontend / backend setup, where the backend serves the dynamic content.
    The frontend is a lightweight WEB server that serves static content and
    delegates request for dynamic content as a proxy to the backend.

    This setup is chosen because generating dynamic content often leads to
    very memory consuming processes and, thus, the necessity to limit their
    number. But such a setup does not forbid using mod_perl also in the
    frontend. Only the memory consumption must be small and limited. Since
    "Apache2::POST200" reads the data from the database one block at a time
    it meets this condition.

    Now look at what happens without "Apache2::POST200". The initial POST
    request as well as the redirected GET occupy a frontend and a backend
    instance. If "Apache2::POST200" is used at the frontend only the initial
    POST involves both frontend and backend. The subsequent GET is handled
    exclusively by the frontend.

    "Apache2::POST200" may be used even at frontend and backend. The output
    filter runs at the backend inserting data in the database. The response
    handler runs at the frontend. Limit the block size in this case with
    "Post200DataBlockSize" to avoid bloating the frontend.

  Repair external WEB applications
    Another useful application of "Apache2::POST200" is to repair external
    applications. Suppose you have a WEB application written in some closed
    language or running on an external server that emits code 200 replies to
    POST requests. Setup a reverse or even forward proxy with
    "Apache2::POST200". It repairs the application without having access to
    it.

TODO
    Caching
        With a keep-alive connection the redirected request is most likely
        to come in over the same connection. Thus, some caching in a
        connection pnote would be good.

    User check
        Client IP checking may not be sufficient. The filter could check
        "$r->user", set a special flag in the redirect param and save the
        user name. The rewrite rules could then check the flag and require a
        valid-user. Then the response handler can verify "$r->user" against
        the saved user.

SEE ALSO
    Apache2::Translation

AUTHOR
    Torsten Foertsch, <torsten.foertsch@gmx.net>

SPONSORING
    Sincere thanks to Arvato Direct Services (http://www.arvato.com/) for
    sponsoring this module.

COPYRIGHT AND LICENSE
    Copyright (C) 2005 by Torsten Foertsch

    This library is free software; you can redistribute it and/or modify it
    under the same terms as Perl itself.



( run in 0.554 second using v1.01-cache-2.11-cpan-63c85eba8c4 )