LWP::UserAgent::CHICaching - LWP::UserAgent with caching based on CHI

       Kjetil Kjernsmo <kjetilk@cpan.org>.

       This software is copyright (c) 2015, 2016 by Kjetil Kjernsmo.

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

       This is YA caching user agent. When the client makes a request to the server, sometimes the response
       should be cached, so that no actual request has to be sent at all, or possibly just a request to validate
       the cache. HTTP 1.1 defines how to do this. This class simply extends LWP::UserAgent with
       LWP::UserAgent::Role::CHICaching (also in this distribution) which is doing the real work to make it
       possible to use the very flexible CHI module to manage such a cache.

       But why? Mainly because I wanted to use CHI facilities, and partly because I wanted to focus on HTTP 1.1
       features.

       THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT  ANY  EXPRESS  OR  IMPLIED  WARRANTIES,  INCLUDING,  WITHOUT
       LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

perl v5.34.0                                       2022-05-28                    LWP::UserAgent::CHICaching(3pm)

       LWP::UserAgent::CHICaching - LWP::UserAgent with caching based on CHI

       The usual way of using LWP::UserAgent, really, just pass a "cache" parameter with a CHI object to the
       constructor:

         my $cache = CHI->new( driver => 'Memory', global => 1 );
         my $ua = LWP::UserAgent::CHICaching->new(cache => $cache);
         my $res1 = $ua->get("http://localhost:3000/?query=DAHUT");

       This is an early release, but it supports RFC7234 quite well already. Much work remains though. These are
       the things that I'd like to do:

       •   Enable  smarter  generation of keys, so that semantically identical content can be cached efficiently
           even though they may have different URIs. This can be done in a separate role with the current code.

       •   Support      all      of      RFC7234      <http://tools.ietf.org/html/rfc7234>      and      RFC7232
           <http://tools.ietf.org/html/rfc7232>