diff --git a/Changes b/Changes
index 8f74b8b..4a4d7ee 100644
--- a/Changes
+++ b/Changes
@@ -11,7 +11,6 @@
             - Module::Template now inserts an 'app' parameter to render variables unless 'app' is already provided
 
             [Changes]
-            - Scalar context behavior of the param method called without arguments on json request is now deprecated
               * this is done in effort to make param method easier to use and harder to misuse
             - Kelp::Test no longer uses HTTP::Cookies, implements a much slimmer cookie jar with the same interface
               * The new cookie jar only stores key/value pairs without any special data for cookies like domains, paths or expiration dates
@@ -30,6 +29,8 @@
             - A template named '0' will now be properly rendered
             - An 'app' object available in Kelp::Response template is now a properly reblessed controller
 
+            [Deprecations]
+            - Scalar context behavior of the param method called without arguments on json request is now deprecated
 
             [Backward-Incompatible Changes]
             - Request data will now be properly decoded using either charset from Content-Type or application charset
diff --git a/lib/Kelp/Manual.pod b/lib/Kelp/Manual.pod
index ad3efbe..eada063 100644
--- a/lib/Kelp/Manual.pod
+++ b/lib/Kelp/Manual.pod
@@ -62,8 +62,46 @@ omitted adding certain components. This is where Kelp gets to shine. It provides
 a layer on top of Plack and puts everything together into a complete web
 framework.
 
+=head2 New Kelp versions and backward compatibility
+
+Major version 2 of Kelp introduced some breaking changes, especially when it
+comes to how requests are decoded and how the errors are rendered. If you are
+affected and don't want to modify your code, you are welcome to use a fixed
+version C<1.07> (before the big changes). You will be missing on a lot of
+improvements though.
+
+Kelp values backward compatibility, but at the same time it will not be
+hesitant to fix bugs, security issues or major inconveniences where it sees
+necessary. From 2.01 forward, non-bugfix breaking changes will only be
+introduced after a 3-month deprecation period. Changelog will list them under
+C<[Deprecations]> section.
+
 =head1 CREATING A NEW WEB APP
 
+=head2 Quick development using Kelp::Less
+
+For writing quick experimental web apps and to reduce the boiler plate, one
+could use L<Kelp::Less>. In this case all of the code can be put in C<app.psgi>:
+Look up the POD for L<Kelp::Less> for many examples, but to get you started off,
+here is a quick one:
+
+    # app.psgi
+    use Kelp::Less;
+
+    module 'JSON';
+
+    get '/api/:user/?action' => sub {
+        my ( $self, $user, $action ) = @_;
+        my $json = {
+            success => \1,
+            user    => $user,
+            action  => $action // 'ask'
+        };
+        return $json;
+    };
+
+    run;
+
 =head2 Using the C<Kelp> script
 
 The easiest way to create the directory structure and a general application
@@ -74,7 +112,7 @@ skeleton is by using the C<Kelp> script, which comes with this package.
 This will create C<lib/MyApp.pm>, C<app.psgi> and some other files (explained
 below).
 
-To create a L<Kelp::Less> app, use:
+To create a L<Kelp::Less> app file, use:
 
     > Kelp --type=less MyApp
 
@@ -230,6 +268,8 @@ L<Kelp::Base>:
 
     1;
 
+=head1 FRAMEWORK BASICS
+
 =head2 Routing
 
 Kelp uses a powerful and very flexible router. Traditionally, it is also light
@@ -387,106 +427,204 @@ the necessary arguments.
 
     my $url = $self->route->url('update', id => 1000); # /update/1000
 
-=head2 Reblessing into controller classes
+=head2 Reading a HTTP request
 
-All of the examples here show routes which take a instance of the web
-application as a first parameter. This is true even if those routes live in
-another class.
+All input data comes nicely packed inside L<Kelp::Request>, which inherits
+Plack::Request. It has a coulpe convenience methods and handles charset
+decoding automatically.
 
-To rebless the app instance into the controller class instance, the controller
-class must extend the class specified in C<base> configuration field. The
-default value of that field is the application class, so your application class
-is by default your main controller class. All other controllers must (directly
-or indirectly) inherit from your application class.
+=head3 Input data charsets
 
-=head3 Step 1: Configure the controller
+All request methods showcased below will try to decode request data with either
+charset from the C<Content-Type> header (if present and supported by L<Encode>
+module) or with application charset otherwise.
 
-It is a good practice to set up a different C<base>, so that you separate general
-app code from request-handling code.
+There are a couple methods starting with C<raw_> which return encoded data. See
+L<Kelp::Request/ENCODING> for details.
 
-    # config.pl
-    {
-        modules_init => {
-            Routes => {
-                rebless => 1, # the app instance will be reblessed
-                base => 'MyApp::Controller',
-            }
-        }
+=head3 C<param> and friends
+
+The request class has a couple of C<param> methods, which allow quick and easy access to request parameters.
+
+    sub fetch_params {
+        my $self = shift;
+        my $key = 'parameter_name';
+
+        # fetch parameters from query form, body form or JSON body
+        my $json_or_body_or_query = $self->param($key);
+        my $always_query = $self->res->query_param($key);
+        my $always_body = $self->res->body_param($key);
+        my $always_json = $self->res->json_param($key);
     }
 
-=head3 Step 2: Create a main controller class
+These C<param> methods return a single value with a C<$key> or a list of
+available keys with no arguments.
 
-This step is only required if you've changed the C<base>.
+=head3 C<parameters> and friends
 
-    # lib/MyApp/Controller.pm
-    package MyApp::Controller;
-    use Kelp::Base 'MyApp';
+These methods return a L<Hash::MultiValue> object with parameters:
 
-    # Now $self is an instance of 'MyApp::Controller';
-    sub service_method {
+    sub fetch_parameters {
         my $self = shift;
-        ...;
+
+        # fetch parameters from query form or body form
+        my $body_or_query = $self->res->parameters($key);
+        my $always_query = $self->res->query_parameters($key);
+        my $always_body = $self->res->body_parameters($key);
     }
 
-    1;
+They may be more useful to get a lot of parameters in one go.
 
-=head3 Step 3: Create any number of controller classes
+=head3 C<content>, C<raw_body> and C<json_content>
 
-They all must inherit from your main controller class.
+These methods return the body of the request.
 
-    # lib/MyApp/Controller/Users.pm
-    package MyApp::Controller::Users;
-    use Kelp::Base 'MyApp::Controller';
+C<content> returns the body properly decoded.
 
-    # Now $self is an instance of 'MyApp::Controller::Users'
-    sub authenticate {
+C<json_content> tries to decode the C<content> as json and return a Perl
+structure or C<undef> on error or if it isn't a json request.
+
+C<raw_body> is same as C<content>, but it has the original request encoding.
+
+=head3 File uploads
+
+The request object has a C<uploads|Plack::Request/uploads> property. The
+uploads property returns a reference to a hash containing all uploads.
+
+    sub upload {
         my $self = shift;
-        ...;
+        my $uploads  = $self->req->uploads;
+
+        # Now $uploads is a hashref to all uploads
+        ...
     }
 
-    1;
+For L<Kelp::Less>, then you can use the C<req> reserved word:
 
-=head3 Step 4: Add routes with shorter class names
+    get '/upload' => sub {
+        my $uploads = req->uploads;
+    };
 
-You no longer have to prefix destinations with the base controller class name.
+=head3 Other request data
 
-    # lib/MyApp.pm
+See L<Kelp::Request> and L<Plack::Request> to see how to fetch some other data
+you may find useful.
 
-    ...
+=head2 Building an HTTP response
 
-    sub build {
+Kelp contains an elegant module, called L<Kelp::Response>, which extends
+C<Plack::Response> with several useful methods. Most methods return C<$self>
+after they do the required job. For the sake of the examples below, let's
+assume that all of the code is located inside a route definition.
+
+=head3 Automatic content type
+
+Your routes don't always have to set the C<response> object. You could just
+return a simple scalar value or a reference to a hash, array or anything that
+can be converted to JSON.
+
+    # Content-type automatically set to "text/html"
+    sub text_route {
+        return "There, there ...";
+    }
+
+    # Content-type automatically set to "application/json"
+    sub json_route {
+        return { error => 1,  message => "Fail" };
+    }
+
+=head3 Automatic charset encoding
+
+With Kelp, you don't have to worry about the encoding of the response - most of
+the methods will automatically encode the response into configured
+application's charset. Plaintext and HTML content types will by default have
+C<charset> part added. To make it all work flawlessly, remember to C<use utf8;>
+at the top of your files.
+
+If you'd like to instead take charset into your own hands, you will have to use
+L<Kelp::Response/render_binary> and manually set content types and charsets.
+
+=head3 Rendering text
+
+    # Render simple text
+    $self->res->text->render("It works!");
+
+=head3 Rendering HTML
+
+    $self->res->html->render("<h1>It works!</h1>");
+
+=head3 Custom content type
+
+    $self->res->set_content_type('image/png');
+
+=head3 Return 404 or 500 errors
+
+    sub some_route {
         my $self = shift;
+        if ($missing) {
+            return $self->res->render_404;
+        }
+        if ($broken) {
+            return $self->res->render_500;
+        }
+    }
 
-        # if 'base' was not changed, this would have to be written as:
-        # => 'Controller::Users::authenticate'
-        $self->add_route('/login' => 'Users::authenticate');
+=head3 Templates
 
+    sub hello {
+        my ( $self, $name ) = @_;
+        $self->res->template( 'hello.tt', { name => $name } );
     }
 
+The above example will render the contents of C<hello.tt>, and it will set the
+content-type to C<text/html>. To set a different content-type, use
+C<set_content_type> or any of its aliases:
 
-=head2 Quick development using Kelp::Less
+    sub hello_txt {
+        my ( $self, $name ) = @_;
+        $self->res->text->template( 'hello_txt.tt', { name => $name } );
+    }
 
-For writing quick experimental web apps and to reduce the boiler plate, one
-could use L<Kelp::Less>. In this case all of the code can be put in C<app.psgi>:
-Look up the POD for C<Kelp::Less> for many examples, but to get you started off,
-here is a quick one:
+=head3 Headers
 
-    # app.psgi
-    use Kelp::Less;
+    $self->set_header( "X-Framework", "Kelp" )->render( { success => \1 } );
 
-    module 'JSON';
+=head3 Serving static files
 
-    get '/api/:user/?action' => sub {
-        my ( $self, $user, $action ) = @_;
-        my $json = {
-            success => \1,
-            user    => $user,
-            action  => $action // 'ask'
-        };
-        return $json;
+If you want to serve static pages, you can use the L<Plack::Middleware::Static>
+middleware that comes with Plack. Here is an example configuration that serves
+files in your C<public> folder (under the Kelp root folder) from URLs that
+begin with C</public>:
+
+    # conf/config.pl
+    {
+        middleware      => [qw/Static/],
+        middleware_init => {
+            Static => {
+                path => qr{^/public/},
+                root => '.',
+            }
+        }
     };
 
-    run;
+=head3 Delayed responses
+
+To send a delayed response, have your route return a subroutine.
+
+    sub delayed {
+        my $self = shift;
+        return sub {
+            my $responder = shift;
+            $self->res->code(200);
+            $self->res->text->body("Better late than never.");
+            $responder->($self->res->finalize);
+        };
+    }
+
+See the L<PSGI|PSGI/Delayed-Response-and-Streaming-Body> pod for more
+information and examples.
+
+=head1 CONFIGURING THE APPLICATION
 
 =head2 Adding middleware
 
@@ -542,221 +680,181 @@ returned app.
 
 Note that any middleware defined in your config file will be added first.
 
-=head2 Testing
+=head2 Pluggable modules
 
-Kelp provides a test class called C<Kelp::Test>. It is object oriented, and all
-methods return the C<Kelp::Test> object, so they can be chained together.
-Testing is done by sending HTTP requests to an already built application and
-analyzing the response. Therefore, each test usually begins with the
-L<Kelp::Test/request> method, which takes a single L<HTTP::Request> parameter.
-It sends the request to the web app and saves the response as an
-L<HTTP::Response> object.
+=head3 How to load modules using the config
 
-    # file t/test.t
-    use MyApp;
-    use Kelp::Test;
-    use Test::More;
-    use HTTP::Request::Common;
+Kelp can be extended using custom I<modules>. There are two modules that are
+B<always> loaded by each application instance. Those are C<Config> and
+C<Routes>. The reason behind this is that each and every application always
+needs a router and configuration. All other modules must be loaded either using
+the L<Kelp/load_module> method, or using the C<modules> key in the
+configuration. The default configuration already loads these modules:
+C<Template>, C<Logger> and C<JSON>. Your configuration can remove some and/or
+add others. The configuration key C<modules_init> may contain hashes with
+initialization arguments. See L<Kelp::Module> for configuration examples.
 
-    my $app = MyApp->new( mode => 'test' );
-    my $t = Kelp::Test->new( app => $app );
+=head3 Creating your own module
 
-    $t->request( GET '/path' )
-      ->code_is(200)
-      ->content_is("It works");
+Each new module must be a
+subclass of the C<Kelp::Module> class. Modules' job is to initialize and
+register new methods into the web application class. Here is a simple module
+which initializes an extremely simple cache:
 
-    $t->request( POST '/api' )
-      ->json_cmp({auth => 1});
+    package Kelp::Module::ExampleCache;
 
-    done_testing;
+    use Kelp::Base 'Kelp::Module';
 
-What is happening here?
+    sub build {
+        my ($self, %args) = @_;
 
-=over
+        my $case_sensitive = !$args{case_insensitive};
+        my %cache;
 
-=item
+        $self->register(cache_set => sub {
+            my ($app, $key, $value) = @_;
+            $cache{$case_sensitive ? $key : lc $key} = $value;
+        });
 
-First, we create an instance of the web application class, which we have
-previously built and placed in the C<lib/> folder. We set the mode of the app to
-C<test>, so that file C<conf/test.pl> overrides the main configuration.
-The test configuration can contain anything you see fit. Perhaps you want to
-disable certain modules, or maybe you want to make DBI connect to a different
-database.
+        $self->register(cache_get => sub {
+            my ($app, $key) = @_;
+            return $cache{$case_sensitive ? $key : lc $key};
+        });
 
-=item
+    }
 
-Second, we create an instance of the C<Kelp::Test> class and tell it that it
-will perform all tests using our C<$app> instance.
+    1;
 
-=item
+What is happening here?
 
-At this point we are ready to send requests to the app via the
-L<request|Kelp::Test/request> method. It takes only one argument, an
-HTTP::Request object. It is very convenient to use the L<HTTP::Request::Common>
-module here, because you can create common requests using abridged syntax,
-i.e. C<GET>, C<POST>, etc.  The line C<$t-E<gt>request( GET '/path' )> first
-creates a HTTP::Request GET object, and then passes it to the C<request> method.
+=over
 
 =item
 
-After we send the request, we can test the response using any of the C<Test::>
-modules, or via the methods provided by L<Kelp::Test>.
-In the above example, we test if we got a code 200 back from C</path> and if the
-returned content was C<It works>.
-
-=back
-
-Run the rest as usual, using C<prove>:
+First we create a class C<Kelp::Module::ExampleCache> which inherits C<Kelp::Module>.
 
-    > prove -l t/test.t
-
-Take a look at the L<Kelp::Test> for details and more examples.
-
-=head2 Building an HTTP response
-
-Kelp contains an elegant module, called L<Kelp::Response>, which extends
-C<Plack::Response> with several useful methods. Most methods return C<$self>
-after they do the required job.
-For the sake of the examples below, let's assume that all of the code is located
-inside a route definition.
+=item
 
-=head3 Automatic content type
+Then, we override the C<build> method (of C<Kelp::Module>), we fetch the
+C<case_insensitive> value from the configuration (configured under
+C<modules_init.ExampleCache.case_insensitive>).
 
-Your routes don't always have to set the C<response> object. You could just
-return a simple scalar value or a reference to a hash, array or anything that
-can be converted to JSON.
+=item
 
-    # Content-type automatically set to "text/html"
-    sub text_route {
-        return "There, there ...";
-    }
+Last step is to initialize the hash which will store the keys and register two
+methods into the web application via the C<register> method. They will be ready
+to use in the main application class.
 
-    # Content-type automatically set to "application/json"
-    sub json_route {
-        return { error => 1,  message => "Fail" };
-    }
+=back
 
-=head3 Rendering text
+See more examples and POD at L<Kelp::Module>.
 
-    # Render simple text
-    $self->res->text->render("It works!");
 
-=head3 Rendering HTML
+=head2 Reblessing into controller classes
 
-    $self->res->html->render("<h1>It works!</h1>");
+All of the examples here show routes which take a instance of the web
+application as a first parameter. This is true even if those routes live in
+another class.
 
-=head3 Custom content type
+To rebless the app instance into the controller class instance, the controller
+class must extend the class specified in C<base> configuration field. The
+default value of that field is the application class, so your application class
+is by default your main controller class. All other controllers must (directly
+or indirectly) inherit from your application class.
 
-    $self->res->set_content_type('image/png');
+=head3 Step 1: Configure the controller
 
-=head3 Return 404 or 500 errors
+It is a good practice to set up a different C<base>, so that you separate general
+app code from request-handling code.
 
-    sub some_route {
-        my $self = shift;
-        if ($missing) {
-            return $self->res->render_404;
-        }
-        if ($broken) {
-            return $self->res->render_500;
+    # config.pl
+    {
+        modules_init => {
+            Routes => {
+                rebless => 1, # the app instance will be reblessed
+                base => 'MyApp::Controller',
+            }
         }
     }
 
-=head3 Templates
+=head3 Step 2: Create a main controller class
 
-    sub hello {
-        my ( $self, $name ) = @_;
-        $self->res->template( 'hello.tt', { name => $name } );
-    }
+This step is only required if you've changed the C<base>.
 
-The above example will render the contents of C<hello.tt>, and it will set the
-content-type to C<text/html>. To set a different content-type, use
-C<set_content_type> or any of its aliases:
+    # lib/MyApp/Controller.pm
+    package MyApp::Controller;
+    use Kelp::Base 'MyApp';
 
-    sub hello_txt {
-        my ( $self, $name ) = @_;
-        $self->res->text->template( 'hello_txt.tt', { name => $name } );
+    # Now $self is an instance of 'MyApp::Controller';
+    sub service_method {
+        my $self = shift;
+        ...;
     }
 
-=head3 Headers
-
-    $self->set_header( "X-Framework", "Kelp" )->render( { success => \1 } );
-
-=head3 Serving static files
-
-If you want to serve static pages, you can use the L<Plack::Middleware::Static>
-middleware that comes with Plack. Here is an example configuration that serves
-files in your C<public> folder (under the Kelp root folder) from URLs that
-begin with C</public>:
+    1;
 
-    # conf/config.pl
-    {
-        middleware      => [qw/Static/],
-        middleware_init => {
-            Static => {
-                path => qr{^/public/},
-                root => '.',
-            }
-        }
-    };
+=head3 Step 3: Create any number of controller classes
 
-=head3 Uploading files
+They all must inherit from your main controller class.
 
-File uploads are handled by L<Kelp::Request>, which inherits Plack::Request
-and has its C<uploads|Plack::Request/uploads> property. The uploads property returns a
-reference to a hash containing all uploads.
+    # lib/MyApp/Controller/Users.pm
+    package MyApp::Controller::Users;
+    use Kelp::Base 'MyApp::Controller';
 
-    sub upload {
+    # Now $self is an instance of 'MyApp::Controller::Users'
+    sub authenticate {
         my $self = shift;
-        my $uploads  = $self->req->uploads;
-
-        # Now $uploads is a hashref to all uploads
-        ...
+        ...;
     }
 
-For L<Kelp::Less>, then you can use the C<req> reserved word:
+    1;
 
-    get '/upload' => sub {
-        my $uploads = req->uploads;
-    };
+=head3 Step 4: Add routes with shorter class names
 
-=head3 Delayed responses
+You no longer have to prefix destinations with the base controller class name.
 
-To send a delayed response, have your route return a subroutine.
+    # lib/MyApp.pm
 
-    sub delayed {
+    ...
+
+    sub build {
         my $self = shift;
-        return sub {
-            my $responder = shift;
-            $self->res->code(200);
-            $self->res->text->body("Better late than never.");
-            $responder->($self->res->finalize);
-        };
+
+        # if 'base' was not changed, this would have to be written as:
+        # => 'Controller::Users::authenticate'
+        $self->add_route('/login' => 'Users::authenticate');
+
     }
 
-See the L<PSGI|PSGI/Delayed-Response-and-Streaming-Body> pod for more
-information and examples.
+=head1 NEXT STEPS
 
-=head2 Pluggable modules
+=head2 Testing
+
+Kelp provides a test class called C<Kelp::Test>. It is object oriented, and all
+methods return the C<Kelp::Test> object, so they can be chained together.
+Testing is done by sending HTTP requests to an already built application and
+analyzing the response. Therefore, each test usually begins with the
+L<Kelp::Test/request> method, which takes a single L<HTTP::Request> parameter.
+It sends the request to the web app and saves the response as an
+L<HTTP::Response> object.
 
-Kelp can be extended using custom I<modules>. Each new module must be a subclass
-of the C<Kelp::Module> namespace. Modules' job is to initialize and register new
-methods into the web application class. The following is the full code of the
-L<Kelp::Module::JSON> for example:
+    # file t/test.t
+    use MyApp;
+    use Kelp::Test;
+    use Test::More;
+    use HTTP::Request::Common;
 
-    package Kelp::Module::JSON;
+    my $app = MyApp->new( mode => 'test' );
+    my $t = Kelp::Test->new( app => $app );
 
-    use Kelp::Base 'Kelp::Module';
-    use JSON;
+    $t->request( GET '/path' )
+      ->code_is(200)
+      ->content_is("It works");
 
-    sub build {
-        my ( $self, %args ) = @_;
-        my $json = JSON::MaybeXS->new(
-            map { $_ => $args{$_} } keys %args
-        );
-        $self->register( json => $json );
-    }
+    $t->request( POST '/api' )
+      ->json_cmp({auth => 1});
 
-    1;
+    done_testing;
 
 What is happening here?
 
@@ -764,44 +862,45 @@ What is happening here?
 
 =item
 
-First we create a class C<Kelp::Module::JSON> which inherits C<Kelp::Module>.
+First, we create an instance of the web application class, which we have
+previously built and placed in the C<lib/> folder. We set the mode of the app to
+C<test>, so that file C<conf/test.pl> overrides the main configuration.
+The test configuration can contain anything you see fit. Perhaps you want to
+disable certain modules, or maybe you want to make DBI connect to a different
+database.
 
 =item
 
-Then, we override the C<build> method (of C<Kelp::Module>), create a new JSON
-object and register it into the web application via the C<register> method.
-
-=back
+Second, we create an instance of the C<Kelp::Test> class and tell it that it
+will perform all tests using our C<$app> instance.
 
-If we instruct our web application to load the C<JSON::MaybeXS> module, it will have a
-new method C<json> which will be a link to the C<JSON::MaybeXS> object initialized in the
-module.
+=item
 
-See more examples and POD at L<Kelp::Module>.
+At this point we are ready to send requests to the app via the
+L<request|Kelp::Test/request> method. It takes only one argument, an
+HTTP::Request object. It is very convenient to use the L<HTTP::Request::Common>
+module here, because you can create common requests using abridged syntax,
+i.e. C<GET>, C<POST>, etc.  The line C<$t-E<gt>request( GET '/path' )> first
+creates a HTTP::Request GET object, and then passes it to the C<request> method.
 
-=head3 How to load modules using the config
+=item
 
-There are two modules that are B<always> loaded by each application instance.
-Those are C<Config> and C<Routes>. The reason behind this is that each and every
-application always needs a router and configuration.
-All other modules must be loaded either using the L<Kelp/load_module> method, or
-using the C<modules> key in the configuration. The default configuration already
-loads these modules: C<Template>, C<Logger> and C<JSON>. Your configuration can
-remove some and/or add others. The configuration key C<modules_init> may contain
-hashes with initialization arguments. See L<Kelp::Module> for configuration
-examples.
+After we send the request, we can test the response using any of the C<Test::>
+modules, or via the methods provided by L<Kelp::Test>.
+In the above example, we test if we got a code 200 back from C</path> and if the
+returned content was C<It works>.
 
-=head1 NEXT STEPS
+=back
 
-To learn more, see the documentation for the following modules:
+Run the rest as usual, using C<prove>:
 
-L<Kelp::Manual::Cookbook>
+    > prove -l t/test.t
 
-L<Kelp>
+Take a look at the L<Kelp::Test> for details and more examples.
 
-L<Kelp::Routes>
+=head2 Common problems and solutions
 
-L<Plack>
+You may want to take a look at our L<Kelp::Manual::Cookbook>.
 
 =head1 SUPPORT
 
diff --git a/lib/Kelp/Request.pm b/lib/Kelp/Request.pm
index 1e7894d..21c9798 100644
--- a/lib/Kelp/Request.pm
+++ b/lib/Kelp/Request.pm
@@ -232,10 +232,10 @@ Starting with version 2.01, Kelp::Request simplifies input handling and
 improves correctness by automatically decoding path, query parameters and body
 parameters.
 
-Headers (so cookies as well) are unaffected, as they aren't
-consistently supported outside of ASCII range. JSON and session are configured
-separately in modules and middlewares, so they must themselves do the proper
-decoding.
+Headers (so cookies as well) are unaffected, as they aren't consistently
+supported outside of ASCII range. JSON now decodes request data into the proper
+charset instead of flat utf8 if so configured. Sessions are configured
+separately in middlewares, so they must themselves do the proper decoding.
 
 Following methods will return values decoded with charset either from
 C<Content-Type> header or the one specified in the app's configuration: