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.
+can't distinguish / vs %2F in paths (in addition to other encoded values).
=head2 use_request_uri_for_path => 1
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).
+Given that this method of path resolution is provably more correct, it is recommended that you use
+this unless you have a specific need to deploy your application in a non-standard environment, and you are
+aware of the implications of not being able to handle encoded URI paths correctly.
+
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
my $scheme = $c->request->secure ? 'https' : 'http';
my $host = $ENV{HTTP_HOST} || $ENV{SERVER_NAME};
my $port = $ENV{SERVER_PORT} || 80;
+
+ # fix up for IIS
+ if ($ENV{SERVER_SOFTWARE} && $ENV{SERVER_SOFTWARE} =~ m{IIS/[6-9]\.\d}) {
+ $ENV{PATH_INFO} =~ s/^\Q$ENV{SCRIPT_NAME}\E//;
+ }
+
my $script_name = $ENV{SCRIPT_NAME};
$script_name =~ s/([^$URI::uric])/$URI::Escape::escapes{$1}/go if $script_name;
# Prepend the headers if they have not yet been sent
if ( $self->_has_header_buf ) {
- $buffer = $self->_clear_header_buf . $buffer;
+ my $headers = $self->_clear_header_buf;
+
+ $buffer = defined $buffer
+ ? $headers . $buffer : $headers;
}
return $self->$orig( $c, $buffer );