- dancer-users - lists.preshweb.co.uk

Output before after
by Maurice Mengel 02 Feb '11

02 Feb '11

Hey perl dancers, is there a way that I can output stuff before I enter in the after route? That way I could emulate enough streaming. Thanks maurice

2 2

Suggestions for improving installation of Dancer::Plugin::Authorize
by Gurunandan Bhat 02 Feb '11

02 Feb '11

The current test of Dancer::Plugin::Authorize fails when installing as a non-root user (perlbrew/cpanm) because it tries (and fails) to create a session_dir. It would really help if this fine module detected $HOME and created the temporary sessions_dir under $HOME instead. Just a suggestion for a really useful module...

2 1

Re: [Dancer-users] Flash Message
by damien krotkine 30 Jan '11

30 Jan '11

Hi ! I've commented on github. Let's swithc to that for the following discussion indeed. Brian, you are more than welcome to participate :) dams On 29 January 2011 14:59, Flavio Poletti <polettix(a)gmail.com> wrote: > Hi all, > I don't know if this mailing list is actually the right place to > continue this discussion about this module implementation, let us know if > you're bored! > I implemented a generic approach and you can find it > here: https://github.com/polettix/Dancer-Plugin-FlashMessage/tree/alternatives > It is based on the configurability of three traits: > * how messages are registered ("queue" option) > * how additional parameters are handled ("arguments" option) > * how messages are flushed away ("dequeue" option). > There is a lot of new meat so I also added the full documentation with some > examples. This implementation is kinda back-compatible, with two outstanding > exceptions: > * persistence has been dropped, even though its functionality has been > absorbed by "dequeue" > * the 'flash' method now only *sets* messages, and it never deletes them. > IMHO, the case for deletion in the code is quite obscure, so I tried to move > this functionality inside the new "flash_flush" registered keyword. It is > anyway possible to revert to the old behaviour if it is considered better. > For any other aspects, the current default values replicate the previous > behaviour. > If it makes sense to you we can add a plethora of tests. > Thank you all for your patience, we'll probably better continue this > discussion on GitHub if you agree. > Flavio. > > > On Fri, Jan 28, 2011 at 7:05 PM, Flavio Poletti <polettix(a)gmail.com> wrote: >> >> >> On Fri, Jan 28, 2011 at 6:52 PM, damien krotkine <dkrotkine(a)gmail.com> >> wrote: >>> >>> On 28 January 2011 18:40, Flavio Poletti <polettix(a)gmail.com> wrote: >>> > Hi, >>> > >>> > the implementation is sound, even though I'd prefer to be able to >>> > set >>> > multiple messages per single channel. If I validate a form, for >>> > example, I'd >>> > like to flash a warning for each field I don't like, not just the last >>> > one. >>> >>> Hm, my brain being what it is on friday night, could you elaborate a >>> bit more ? can you give an example of such channels ? >>> >>> I'm thinking you could use an array of string as flash.warnings, >>> instead of a simple string, but I'm not sure I understand what you're >>> saying >> >> >> >> Sorry, you got the "channel" idea. I'd like to use flash like this: >> >> flash warning => 'you made error X'; >> >> and then, possibly later, say: >> >> flash warning => 'you made error Y'; >> >> In the current implementation, only the last gets to the template. I'm >> suggesting to always push the incoming $value into an array. Otherwise, with >> the current implementation that lets you delete stuff, I'd be forced to do >> it like this: >> >> my $array = flash('warning') || []; >> push @$array, 'you made error X'; >> flash warning => $array; >> >> which is a bit ugly... >> >> >>> >>> > On the other hand, deleting flash messages from the controller does >>> > seem to >>> > be a corner case, which I'd handle with an ad-hoc function or ignore >>> > completely. >>> > >>> > I'll try to propose something on GitHub that lets the end user decide >>> > the >>> > preferred semantics through a configuration; I would personally like to >>> > avoid having leftovers in the flash when my templates are not bug-free >>> > and I >>> > definitely don't like the idea of remembering to call flash->flush() >>> >>> I agree. After all, maybe it would make sense to have 3 behaviors : >>> behaviour 1 : delete all the keys as soon as one is used (to be >>> implemented ) >>> behaviour 2 : delete only the key which is used ( current implementation >>> ) >>> behaviour 3 : never delete the keys ( currently persistence = 1 ) >>> >>> And maybe behaviour 1 should be the default, I don't know. As long as >>> behaviour 2 is available, I'm happy (and brian too) >>> >>> maybe the behaviour could be chosen with the persistence config >>> keyword ? It could be renamed to flush_behaviour >>> >>> flush_behaviour = key_level >>> flush_behaviour = hash_level >>> flush_behaviour = never >>> >>> What do you think ? OK I'm terrible at finding good names, so any help >>> welcome :) >> >> >> I'd leave "_behaviour", add an 'always' (your previous implementation) and >> put something like: >> >> flush = 'key' >> flush = 'all' >> flush = 'always' >> flush = 'never' >> >> Anyway, as long as it's documented and it's reasonably connected to the >> behaviour everything is fine :-) >> >> >>> >>> > (even >>> > though it sounds so nice!) >>> >>> aha, yes, I like flash->flush :) Let's add it for fun, even if it's >>> not necessary :) >>> >>> >>> > >>> > Cheers, >>> > >>> > Flavio. >>> > >>> > On Fri, Jan 28, 2011 at 6:33 PM, damien krotkine <dkrotkine(a)gmail.com> >>> > wrote: >>> >> >>> >> I agree with Brian, for a slightly different reason : >>> >> >>> >> Let's imagine this: >>> >> >>> >> you have a Template1, that does this : <% flash.keys() %>, to be able >>> >> to know that they are errors. If that's the case, it doesn't display >>> >> the errors, but display a link, saying that they are erros. This link >>> >> does a new request against the server, serving Template2 >>> >> >>> >> Template2 does use flash.error, and effectively consumes the message. >>> >> >>> >> You don't want the flash hash structure to be emptied just after >>> >> having displayed Template1, you want the messages to survive until >>> >> Template2 (after all, you didn't consume them in Template1) >>> >> >>> >> If I understand correctly, In the original implementation, the simple >>> >> fact of getting the keys of the hash would delete all the messages, so >>> >> the next request, Template2 won't be able to retrieve <% flash.error >>> >> %> >>> >> >>> >> In my new implementation, it would work. >>> >> >>> >> Granted, this is a bit of a corner case, however, I don't see any >>> >> drawback. >>> >> >>> >> I could also add a flash->flush() method. >>> >> >>> >> >>> >> On 28 January 2011 18:09, Brian E. Lozier <brian(a)massassi.com> wrote: >>> >> > I can't think of any real world use case where you'd only want to >>> >> > show >>> >> > certain messages. That said, it still seems better to only clear >>> >> > the >>> >> > messages you use, not all of them. >>> >> > >>> >> > On Fri, Jan 28, 2011 at 9:02 AM, Flavio Poletti <polettix(a)gmail.com> >>> >> > wrote: >>> >> >> Hi, >>> >> >> >>> >> >> of course we can try to adapt to it (it seems a bit difficult >>> >> >> although >>> >> >> probably not impossible), but I fail to see the point. >>> >> >> >>> >> >> IMHO, if you get the chance to show the messages, you should show >>> >> >> them >>> >> >> all: >>> >> >> showing warnings in one page and errors in the following one would >>> >> >> puzzle >>> >> >> the end user, wouldn't it? >>> >> >> >>> >> >> Unless there is some use case that point in the opposite direction >>> >> >> I'd >>> >> >> stick >>> >> >> to the "wipe them all when you get the chance to show them" >>> >> >> semantics. >>> >> >> >>> >> >> Cheers, >>> >> >> >>> >> >> Flavio. >>> >> >> >>> >> >> On Fri, Jan 28, 2011 at 5:32 PM, Brian E. Lozier >>> >> >> <brian(a)massassi.com> >>> >> >> wrote: >>> >> >>> >>> >> >>> It looks like a pretty good solution. The only thing I can see >>> >> >>> would >>> >> >>> be that if you are in a template and check for flash.error but not >>> >> >>> flash.warning, it looks like it will clear both flash.error and >>> >> >>> flash.warning. It seems like it should only clear the one you're >>> >> >>> checking for. >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> On Fri, Jan 28, 2011 at 12:02 AM, Flavio Poletti >>> >> >>> <polettix(a)gmail.com> >>> >> >>> wrote: >>> >> >>> > Hi, >>> >> >>> > I thought a bit about it and I think that the current >>> >> >>> > implementation >>> >> >>> > is a >>> >> >>> > bit too limited (this seems also what brian thinks in the bug >>> >> >>> > report http://rt.cpan.org/Public/Bug/Display.html?id=65009 - at >>> >> >>> > least >>> >> >>> > from >>> >> >>> > what I understand). >>> >> >>> > The problem is that the flash message might have to be displayed >>> >> >>> > in >>> >> >>> > the >>> >> >>> > next >>> >> >>> > request, which happens when redirections kick in. In this case, >>> >> >>> > the >>> >> >>> > flash >>> >> >>> > message should be set, kept in the session and removed only when >>> >> >>> > it >>> >> >>> > is >>> >> >>> > actually displayed; this should happen automatically, i.e. >>> >> >>> > without >>> >> >>> > playing >>> >> >>> > with the $persistent variable - which is global - or with >>> >> >>> > further >>> >> >>> > overhead >>> >> >>> > on the controller side. >>> >> >>> > Following brian's feedback, I tried to re-code the plugin with >>> >> >>> > the >>> >> >>> > following >>> >> >>> > criteria: >>> >> >>> > * the "flash" method only adds messages (and handles many of >>> >> >>> > them >>> >> >>> > for >>> >> >>> > every >>> >> >>> > category - you might have more than one error in a page). I see >>> >> >>> > no >>> >> >>> > point >>> >> >>> > in >>> >> >>> > removing messages while inside the controller; >>> >> >>> > * the message removal logic is shifted in the template via an >>> >> >>> > anonymous >>> >> >>> > sub. >>> >> >>> > If the sub is called then the flash cache is cleared, otherwise >>> >> >>> > it >>> >> >>> > remains >>> >> >>> > there. This should guarantee that the messages are not removed >>> >> >>> > until >>> >> >>> > they >>> >> >>> > get the chance to be displayed. >>> >> >>> > This is the core of the recoding - not tested but should suffice >>> >> >>> > to >>> >> >>> > give >>> >> >>> > you >>> >> >>> > the idea: >>> >> >>> > register flash => sub { >>> >> >>> > my ($key, $value) = @_; >>> >> >>> > my $flash = session($session_hash_key); >>> >> >>> > if (! $flash) { # initialise the container for flash >>> >> >>> > messages >>> >> >>> > $flash = {}; >>> >> >>> > session($session_hash_key, $flash); >>> >> >>> > } >>> >> >>> > push @{$flash->{$key}}, $value; >>> >> >>> > return; >>> >> >>> > }; >>> >> >>> > before_template sub { >>> >> >>> > my $obj = shift; >>> >> >>> > my $flashes; >>> >> >>> > $obj->{$token_name} = sub { >>> >> >>> > if (! $flashes) { # first call, get messages and clear >>> >> >>> > $flashes = session($session_hash_key) || {}; >>> >> >>> > session($session_hash_key, {}); >>> >> >>> > } >>> >> >>> > return $flashes; >>> >> >>> > }; >>> >> >>> > return; >>> >> >>> > }; >>> >> >>> > >>> >> >>> > IMHO there is no need for an "exists", in the template you can >>> >> >>> > do >>> >> >>> > like >>> >> >>> > this: >>> >> >>> > <% IF flash.errors %>...<% END %> >>> >> >>> > The important thing to remember is that even checking for the >>> >> >>> > presence >>> >> >>> > of >>> >> >>> > something inside "flash" clears the messages, which is >>> >> >>> > consistent >>> >> >>> > with >>> >> >>> > the >>> >> >>> > semantics that "they get cleared as soon as they have a chance >>> >> >>> > to be >>> >> >>> > displayed". The $flashes variable guarantees that they survive >>> >> >>> > at >>> >> >>> > least >>> >> >>> > until the end of the request, i.e. you are able to call "flash" >>> >> >>> > multiple >>> >> >>> > times while handling a request and always get all messages. >>> >> >>> > If you think that this makes sense, I can propose a pull request >>> >> >>> > on >>> >> >>> > GitHub >>> >> >>> > or you can make the changes directly. >>> >> >>> > Cheers, >>> >> >>> > Flavio. >>> >> >>> > >>> >> >>> > >>> >> >>> > On Tue, Jan 11, 2011 at 5:48 PM, damien krotkine >>> >> >>> > <dkrotkine(a)gmail.com> >>> >> >>> > wrote: >>> >> >>> >> >>> >> >>> >> I've re-implemented it to be more Rails-like, as sukria said. >>> >> >>> >> >>> >> >>> >> https://github.com/dams/Dancer-Plugin-FlashMessage >>> >> >>> >> >>> >> >>> >> and on CPAN, pending mirrors refresh. >>> >> >>> >> >>> >> >>> >> The funny part of the story ? the effective code is only 30 >>> >> >>> >> lines >>> >> >>> >> long. Talking about Perl and Dancer expressiveness... >>> >> >>> >> >>> >> >>> >> dams. >>> >> >>> >> >>> >> >>> >> On 11 January 2011 14:40, Alexis Sukrieh <sukria(a)sukria.net> >>> >> >>> >> wrote: >>> >> >>> >> > Hi list! >>> >> >>> >> > >>> >> >>> >> > Le 11/01/2011 14:29, damien krotkine a écrit : >>> >> >>> >> >> >>> >> >>> >> >> Hi, >>> >> >>> >> >> >>> >> >>> >> >> following previous thread, I've done a first implementation >>> >> >>> >> >> of >>> >> >>> >> >> Dancer::Plugin::FlashMessage : >>> >> >>> >> >> >>> >> >>> >> >> https://github.com/dams/Dancer-Plugin-FlashMessage >>> >> >>> >> > >>> >> >>> >> > Great! Thanks a lot for your time dams, the myth is still >>> >> >>> >> > alived! >>> >> >>> >> > (Dancer's >>> >> >>> >> > community)++ >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> >> Some parts need to be improved, for instance : >>> >> >>> >> >> >>> >> >>> >> >> - it supports only one flash message >>> >> >>> >> >> - the keywords are not short enough. >>> >> >>> >> >> >>> >> >>> >> >> So I think I'll change the implementation so that the >>> >> >>> >> >> template >>> >> >>> >> >> token >>> >> >>> >> >> is >>> >> >>> >> >> simply called 'flash', and it'll be a hash, like in Rails. >>> >> >>> >> >> I'll >>> >> >>> >> >> also >>> >> >>> >> >> change the registered method so that it's just flash() >>> >> >>> >> >> instead >>> >> >>> >> >> of >>> >> >>> >> >> get_flash() >>> >> >>> >> > >>> >> >>> >> > I agree. I'd like to behave just like Rails' flash feature. >>> >> >>> >> > The >>> >> >>> >> > idea >>> >> >>> >> > is >>> >> >>> >> > pretty straight forward: >>> >> >>> >> > >>> >> >>> >> > "flash" is an accessor to a particular session hash table >>> >> >>> >> > whose >>> >> >>> >> > values >>> >> >>> >> > can >>> >> >>> >> > only be accessed once. Nothing more complicated than that. >>> >> >>> >> > >>> >> >>> >> > So to conclude, IMO, flash should be a wrapper like the >>> >> >>> >> > following: >>> >> >>> >> > >>> >> >>> >> > sub flash { >>> >> >>> >> > my ($key, $value) = @_; >>> >> >>> >> > my $flash = session('_flash'); >>> >> >>> >> > >>> >> >>> >> > # write >>> >> >>> >> > if (@_ == 2) { >>> >> >>> >> > $flash->{$key} = $value; >>> >> >>> >> > session('_flash' => $flash); >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > # read (+ delete) >>> >> >>> >> > else { >>> >> >>> >> > my $value = $flash->{$key}; >>> >> >>> >> > delete $flash->{$key} if defined $value; >>> >> >>> >> > session('_flash' => $flash); >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > return $value; >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > This is it, I think. This allows for the following code in a >>> >> >>> >> > Dancer >>> >> >>> >> > app: >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > get '/' => sub { >>> >> >>> >> > flash welcome => "This is a welcome message, only >>> >> >>> >> > shown >>> >> >>> >> > once"; >>> >> >>> >> > } >>> >> >>> >> > >>> >> >>> >> > Then, as soon as the key 'welcome' is accesed via >>> >> >>> >> > flash('welcome'), >>> >> >>> >> > the >>> >> >>> >> > entry will be purged. >>> >> >>> >> > >>> >> >>> >> > This will be very helpful for authentication stuff in before >>> >> >>> >> > filters, >>> >> >>> >> > error >>> >> >>> >> > messages, notifications, .... >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > Kudos to dams! >>> >> >>> >> > >>> >> >>> >> > (BTW I haven't read the code yet) >>> >> >>> >> > >>> >> >>> >> > -- >>> >> >>> >> > Alexis Sukrieh >>> >> >>> >> > _______________________________________________ >>> >> >>> >> > Dancer-users mailing list >>> >> >>> >> > Dancer-users(a)perldancer.org >>> >> >>> >> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >>> >> > >>> >> >>> >> _______________________________________________ >>> >> >>> >> Dancer-users mailing list >>> >> >>> >> Dancer-users(a)perldancer.org >>> >> >>> >> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >>> > >>> >> >>> > >>> >> >>> > _______________________________________________ >>> >> >>> > Dancer-users mailing list >>> >> >>> > Dancer-users(a)perldancer.org >>> >> >>> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >>> > >>> >> >>> > >>> >> >>> _______________________________________________ >>> >> >>> Dancer-users mailing list >>> >> >>> Dancer-users(a)perldancer.org >>> >> >>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> >> >>> >> >> >>> >> > _______________________________________________ >>> >> > Dancer-users mailing list >>> >> > Dancer-users(a)perldancer.org >>> >> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >>> >> > >>> > >>> > >> > >

2 1

Re: [Dancer-users] Matching a route including slashes (for directory listing)
by Joel Roth 30 Jan '11

30 Jan '11

On Sun, Jan 30, 2011 at 02:25:53PM +0200, sawyer x wrote: > On Sun, Jan 30, 2011 at 2:21 PM, Al Newkirk & Associates <we(a)ana.im> wrote: > > > On Sun, Jan 30, 2011 at 5:05 AM, sawyer x <xsawyerx(a)gmail.com> wrote: > > > >> On Sun, Jan 30, 2011 at 11:46 AM, Joel Roth <joelz(a)pobox.com> wrote: > >> > >> Hey Joel, > >> > >> If you know the level, and you want to be explicit, you can try the > >> default route syntax: '/media/*/*'. Thanks. Will test this out. > >> However, you will most likely prefer a regular expression (which you tried > >> earlier), and Dancer allows that very easily since Perl considers regexes as > >> first class: > >> get qr/.../ => sub { ... }; Of course. I shouldn't have confined my thinking to the cookbook/introduction. > >> We prefer to wrap qr() with something other than slashes, so we don't get > >> into a backslash fight: > >> get qr{ / media / (.*) }x => sub { ... }; \o/ > > >> Enjoy! > >> > >> > > I feel compelled to caution about how the use of regexs can open security > > holes in your application. Thanks for bringing this up. > > Another way to go would be to traverse the directory(s) and generate routes > > based on the findings in a before action. That was how I had originally done it, one level only, generating a page to represent the contents, as a cron job. A dynamic approach seemed easier, and suitable for this small site. Perhaps I'll go back to that, after trying out the regexen-- at least for my own satisfaction. Thanks to all! Joel > > That's a good point and a good idea! > > Thanks, Al! -- Joel Roth

1 0

Flash Message
by damien krotkine 30 Jan '11

30 Jan '11

Hi, following previous thread, I've done a first implementation of Dancer::Plugin::FlashMessage : https://github.com/dams/Dancer-Plugin-FlashMessage Some parts need to be improved, for instance : - it supports only one flash message - the keywords are not short enough. So I think I'll change the implementation so that the template token is simply called 'flash', and it'll be a hash, like in Rails. I'll also change the registered method so that it's just flash() instead of get_flash() Anything else you think should be changed/added ? Thanks. dams

6 18

Matching a route including slashes (for directory listing)
by Joel Roth 30 Jan '11

30 Jan '11

Hi all, I'm trying to create an Apache-style directory view with links to files and subdirectories and showing file length. I'm attempting to match a route like '/media/foo/bar' and generate a directory listing for /public/foo/bar. I was playing with this tonight: get '/media/*' => sub { my $path = splat; ... } This matches '/media/foo' but I was expecting it to match '/media/foo/bar'. It appears that * doesn't match slashes. '/media/([\w/]+)' doesn't seem to work, either. I'd welcome suggestions for either problem: 1. matching paths with several levels of hierarchy 2. listing a directory Kind regards, Joel -- Joel Roth

3 3

PerlDancer - The easiest way to write web applications with Perl
by Puneet Kishor 28 Jan '11

28 Jan '11

Congratulations on the new web site. Looks gorgeous. http://perldancer.org/ -- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ===========================================================================

2 1

Forward and accent
by Eric Guirbal 28 Jan '11

28 Jan '11

Hello, With dancer 1.3001, the new forward method doesn't work correctly with non ascii characters. $ dancer -a test In index.tt: <blockquote> Avant de choisir le prénom d'un garçon, pensez toujours à la femme qui aura à le murmurer plus tard. </blockquote> In test.pm add the route: get '/quote' => sub { forward '/'; } Run the application standalone et point your browser at http://localhost:3000/quote to see something awful. Regards, -- Eric

3 3

path_info is not set up
by Иван Бессарабов 27 Jan '11

27 Jan '11

I'm running dancer app with plackup: DANCER_ENVIRONMENT='development' plackup -s FCGI --port 3001 myapp.pl I'm using nginx as a web sever. Here is part of its config: server { listen 3000; location / { fastcgi_pass 127.0.0.1:3001; include /etc/nginx/fastcgi_params; } } With this configuration I can access the main page of my app, but only it. In development.log I always get: [27975] core @0.000759> request: GET / from 1.1.1.1 in /usr/share/perl5/Dancer/Handler.pm l. 49 To find out why this is so I've added 3 lines to before sub in my app: debug request->{path}; debug request->path_info(); debug request->to_string(); After restarting plackup, I access "/": [28457] core @0.000769> request: GET / from 1.1.1.1 in /usr/share/perl5/Dancer/Handler.pm l. 49 ... [28457] debug @0.035033> [hit #1]/ in /var/www/myapp/lib/myapp.pm l. 41 [28457] debug @0.035033> [hit #1]/ in /var/www/myapp/lib/myapp.pm l. 42 [28457] debug @0.038886> [hit #1][#1] GET / in /var/www/myapp/lib/myapp.pm l. 43 And here is the log when I try to access "/abc" (in the browser I still see the main page): [28457] core @0.000246> request: GET / from 1.1.1.1 in /usr/share/perl5/Dancer/Handler.pm l. 49 ... [28457] debug @0.016833> [hit #2]/abc in /var/www/myapp/lib/myapp.pm l. 41 [28457] debug @0.018028> [hit #2]/ in /var/www/myapp/lib/myapp.pm l. 42 [28457] debug @0.018363> [hit #2][#2] GET /abc in /var/www/myapp/lib/myapp.pm l. 43 I looked through the dancer code and found out that is be because $self->{env}->{'PATH_INFO'} is empty line in sub _build_path_info in the file Request.pm A dirty workaroud is to place "request->path_info(request->{path});" in before sub in the app. But this is bad because redirects do not work. So. My question is: how can I fix populating PATH_INFO in my app, running with plackup and nginx.

3 4

back to "status code needs to be greater than or equal to 100"
by Puneet Kishor 26 Jan '11

26 Jan '11

Hi all, look at http://punkish.org/PDL-Functions I don't know what even the purpose or value of this error message is, but it is so generic and useless that when I get it, I begin to fear for the lost of a few hours spent debugging. -- Puneet Kishor

2 2