Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Plack-App-Path-Router CPAN distribution.

Report information
The Basics
Id: 78511
Status: open
Priority: 0/
Queue: Plack-App-Path-Router

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.05
Fixed in: (no value)



Subject: Feature: Optionally adjust PATH_INFO and SCRIPT_NAME, like URLMap
Plack::App::URLMap modifies PATH_INFO and SCRIPT_NAME in the psgi environment, making it easy to nest applications in nested paths and other nifty dispatching goodness. This feature could be added with an option, used thusly: package MyApp; my $router = Path::Router->new; $router->add_route('/foo' => target => sub { my ($env) = @_; # this should have '/foo' stripped from path_info and stored in # script_name. warn "my path here is ", $env->{PATH_INFO}; warn "my script_name here is ", $ENV->{SCRIPT_NAME}; # return response... } ); my $app = Plack::App::Path::Router::Custom->new( router => $router, rewrite_script_name => 1, ); rough implementation sketch (untested): package Plack::App::Path::Router::Custom; has rewrite_script_name => ( is => 'ro', isa => 'Bool', default => 0, ); sub call { my ($self, $env) = @_; my $path_info = $env->{PATH_INFO}; my $script_name = $env->{SCRIPT_NAME}; my $match = $self->router->match( $env->{PATH_INFO} ); my $orig_path_info = $env->{PATH_INFO}; my $orig_script_name = $env->{SCRIPT_NAME}; my $location = $match->path; my $path = $env->{PATH_INFO}; $path =~ s!^\Q$location\E!!; $env->{PATH_INFO} = $path; $env->{SCRIPT_NAME} = $script_name . $location; # note this is constructed *after* we alter $env my $req = $self->new_request( $env ); if ($match) { ... unchanged to getting $res # Note that the original ::Custom code doesn't call # response_cb at all, which I'd consider a bug return $self->response_cb($app->($env), sub { $env->{PATH_INFO} = $orig_path_info; $env->{SCRIPT_NAME} = $orig_script_name; }); } }
Subject: Re: [rt.cpan.org #78511] Feature: Optionally adjust PATH_INFO and SCRIPT_NAME, like URLMap
Date: Sat, 21 Jul 2012 15:52:44 -0500
To: Karen Etheridge via RT <bug-Plack-App-Path-Router [...] rt.cpan.org>
From: Jesse Luehrs <doy [...] tozt.net>
On Sat, Jul 21, 2012 at 04:44:17PM -0400, Karen Etheridge via RT wrote: Show quoted text
> Plack::App::URLMap modifies PATH_INFO and SCRIPT_NAME in the psgi > environment, making it easy to nest applications in nested paths and > other nifty dispatching goodness. > > This feature could be added with an option, used thusly: > > package MyApp; > > my $router = Path::Router->new; > $router->add_route('/foo' => > target => sub { > my ($env) = @_; > > # this should have '/foo' stripped from path_info and stored in > # script_name. > warn "my path here is ", $env->{PATH_INFO}; > warn "my script_name here is ", $ENV->{SCRIPT_NAME}; > > # return response... > } > ); > my $app = Plack::App::Path::Router::Custom->new( > router => $router, > rewrite_script_name => 1, > );
I disagree. Plack::App::URLMap and Plack::App::Path::Router are used for different things. If you did this, $env->{PATH_INFO} would never be anything other than '/', because that's how Path::Router routing works (/foo/bar doesn't match a route of /foo). This doesn't really seem very useful. -doy
Show quoted text
> I disagree. Plack::App::URLMap and Plack::App::Path::Router are used > for > different things. If you did this, $env->{PATH_INFO} would never be > anything other than '/', because that's how Path::Router routing works > (/foo/bar doesn't match a route of /foo). This doesn't really seem > very > useful.
ah ok, sounds like I don't understand what is in $match->path. I think you see what I'm intending though. This could be done manually inside every $app subref, but this wouldn't be as clean -- it would either need to be done in a wrapper subref around the $app, or the $app itself would have to have some logic for this... Does Path::Router have the ability to wildcard-match against a path? that wildcard is what would belong in the new PATH_INFO... this really comes back to my first request, "more docs please on the syntax for specifying matches" :)