Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

immutable $c->req (Catalyst::Request) #85

Open
jhannah opened this issue Feb 19, 2015 · 7 comments
Open

immutable $c->req (Catalyst::Request) #85

jhannah opened this issue Feb 19, 2015 · 7 comments

Comments

@jhannah
Copy link
Contributor

jhannah commented Feb 19, 2015

It seems to me life would be better if $c->req could not be altered. It's very tempting for Catalyst newbs (myself included, years ago) to alter the http request (filling it with lies), and then regret it later when MyApp grows. Better to stop people from shooting themselves in their future feet. Thanks.

@belden
Copy link

belden commented Feb 19, 2015

Maybe a plugin that makes the request immutable?

@jhannah
Copy link
Contributor Author

jhannah commented Feb 19, 2015

-shrug- When I was learning Catalyst I had already shot myself in the foot long before I would have ever thought to go looking for plugins to stop me from doing something I didn't know was Bad. I would think it best for Catalyst to ship with the safety on. :)

@jjn1056
Copy link
Member

jjn1056 commented Feb 20, 2015

@jhannah I agree the point of catalyst (or one of its reasons to exist) is to guide newbies toward the right thing. I'd like to see Req fully immutable. We might start with a config switch on post params and headers and the PSGI env. I could default to sane mode but let people set a evil switch, something like $app->config->{mutable_request} =1 in case it breaks code for people.

I think that's a pretty doable thing.

@jhannah
Copy link
Contributor Author

jhannah commented Feb 20, 2015

++ I'm all for MYAPP_MUTABLE_REQUEST=1 or whatever. This is Perl after all, people should be free to shoot themselves however they see fit. :) If I should hack something as a pull request, just point me at wherever you want me and I'm happy to do the footwork. (I have not dabbled in PSGI guts before.)

@perl-catalyst-sync
Copy link

I think even just setting the request attributes to 'ro' and making sure
you can't change request headers and parameters would be a good first step.
maybe even just start with test cases like like would be good

On Thu, Feb 19, 2015 at 6:39 PM, Jay Hannah notifications@github.com
wrote:

++ I'm all for MYAPP_MUTABLE_REQUEST=1 or whatever. This is Perl after
all, people should be free to shoot themselves however they see fit. :) If
I should hack something as a pull request, just point me at wherever you
want me and I'm happy to do the footwork. (I have not dabbled in PSGI guts
before.)


Reply to this email directly or view it on GitHub
#85 (comment)
.

@vanstyn
Copy link
Member

vanstyn commented Feb 20, 2015

There are cases where it is useful and/or needed to modify the request. One such example was in the advent calendar: http://www.catalystframework.org/calendar/2014/18

I'm fine with a config option, but as there are projects and code which rely on the current behavior, I can't see this ever being made a default

@perl-catalyst-sync
Copy link

I think we could still make request immutable but make it more obivous how
to create a new, clean context from the application object, rather than
modify the existing one. but I agree that use case needs to be supported
one way or another.

On Fri, Feb 20, 2015 at 1:17 PM, Henry Van Styn notifications@github.com
wrote:

There are cases where it is useful and/or needed to modify the request.
One such example was in the advent calendar:
http://www.catalystframework.org/calendar/2014/18

I'm fine with a config option, but as there are projects and code which
rely on the current behavior, I can't see this ever being made a default


Reply to this email directly or view it on GitHub
#85 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants