[Catalyst-commits] r13261 - in Catalyst-Runtime/5.80/branches/fix_request_uri/lib: . Catalyst/Engine

[t0m at dev.catalyst.perl.org]

Author: t0m
Date: 2010-05-15 10:20:16 +0100 (Sat, 15 May 2010)
New Revision: 13261

Modified:
   Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst.pm
   Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst/Engine/CGI.pm
Log:
Add a pile of docs for the new use_request_uri_for_path setting

Modified: Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst/Engine/CGI.pm
===================================================================
--- Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst/Engine/CGI.pm	2010-05-15 08:52:16 UTC (rev 13260)
+++ Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst/Engine/CGI.pm	2010-05-15 09:20:16 UTC (rev 13261)
@@ -28,6 +28,39 @@
 
 This is the Catalyst engine specialized for the CGI environment.
 
+=head1 PATH DECODING
+
+Most web server environments pass the requested path to the application using environment variables,
+from which Catalyst has to reconstruct the request base (i.e. the top level path to / in the application,
+exposed as C<< $c->request->base >>) and the request path below that base.
+
+There are two methods of doing this, both of which have advantages and disadvantages. Which method is used
+is determined by the C<< $c->config(use_request_uri_for_path) >> setting (which can either be true or false).
+
+=head2 use_request_uri_for_path => 0
+
+This is the default (and the) traditional method that Catalyst has used for determining the path information.
+The path is synthesised from a combination of the C<PATH_INFO> and C<SCRIPT_NAME> environment variables.
+The allows the application to behave correctly when C<mod_rewrite> is being used to redirect requests
+into the application, as these variables are adjusted by mod_rewrite to take account for the redirect.
+
+However this method has the major disadvantage that it is impossible to correctly decode some elements
+of the path, as RFC 3875 says: "C<< Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot
+contain path-segment parameters. >>" This means PATH_INFO is B<always> decoded, and therefore Catalyst
+can't distinguish / vs %2F in paths.
+
+=head2 use_request_uri_for_path => 1
+
+This method uses the C<REQUEST_URI> and C<SCRIPT_NAME> environment variables. As C<REQUEST_URI> is never
+decoded, this means that applications using this mode can correctly handle URIs including the %2F character
+(i.e. with C<AllowEncodedSlashes> set to C<On> in Apache).
+
+However it also means that in a number of cases when the app isn't installed directly at a path, but instead
+is having paths rewritten into it (e.g. as a .cgi/fcgi in a public_html directory, with mod_rewrite in a
+.htaccess file, or when SSI is used to rewrite pages into the app, or when sub-paths of the app are exposed
+at other URIs than that which the app is 'normally' based at with C<mod_rewrite>), the resolution of
+C<< $c->request->base >> will be incorrect.
+
 =head1 OVERLOADED METHODS
 
 This class overloads some methods from C<Catalyst::Engine>.

Modified: Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst.pm
===================================================================
--- Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst.pm	2010-05-15 08:52:16 UTC (rev 13260)
+++ Catalyst-Runtime/5.80/branches/fix_request_uri/lib/Catalyst.pm	2010-05-15 09:20:16 UTC (rev 13261)
@@ -2946,6 +2946,12 @@
 
 =item *
 
+C<use_request_uri_for_path> - Controlls if the C<REQUEST_URI> or C<PATH_INFO> environment
+variable should be used for determining the request path. See L<Catalyst::Engine::CGI/PATH DECODING>
+for more information.
+
+=item *
+
 C<using_frontend_proxy> - See L</PROXY SUPPORT>.
 
 =back