case insensitive param keys
When Dancer::Request::_parse_get_params() parses the QUERY_STRING (as I assume the post body), it leaves the key names in whatever case they come in as. I checked some RFCs (http://tools.ietf.org/html/rfc3986#section-6.2.3) to see if there was anything definitive, but not really that I could find.
From a pragmatic perspective, it would be nice to have the keys forced to lowercase by Dancer::Request. If you control every link to your application, then you can do this yourself, but if you have links coming in from external sites, and someone chooses to link to your site as
http://www.example.com/?MyPaRAM=Whatever then simple code in Dancer expecting to see params->{myparam} will silently fail. Is this intentional behavior that I need to code around in my app, or something that could be fixed in Dancer::Request? Thanks in advance, Mike. PS: Does anyone know of a good way to search the archives for this list other than using a site: param on google?
Hey. On Wed, Oct 6, 2010 at 4:14 PM, Mike Schroeder <mike@donor.com> wrote:
From a pragmatic perspective, it would be nice to have the keys forced to lowercase by Dancer::Request.
That's a good suggestion and pretty simple to do. Generally opening a ticket with Github would help make this a reality much sooner.[1] :) Sawyer. [1] or if wanted, it would a good reason why and a history to remember why it was rejected - though we usually don't reject! ;)
Thanks Sawyer. Added. http://github.com/sukria/Dancer/issues/issue/138 Mike On Wed, Oct 6, 2010 at 8:36 AM, sawyer x <xsawyerx@gmail.com> wrote:
Hey.
On Wed, Oct 6, 2010 at 4:14 PM, Mike Schroeder <mike@donor.com> wrote:
From a pragmatic perspective, it would be nice to have the keys forced to lowercase by Dancer::Request.
That's a good suggestion and pretty simple to do.
Generally opening a ticket with Github would help make this a reality much sooner.[1] :)
Sawyer.
[1] or if wanted, it would a good reason why and a history to remember why it was rejected - though we usually don't reject! ;)
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
From a pragmatic perspective, it would be nice to have the keys forced to lowercase
"lowercase" ... in which locale? IMHO this should be an option, not the default behavior, especially since this really is done to hide bugs in external applications. A developer facing the issue (i.e., incorrect HTTP calls to his application) can always rewrite the params hash using something like (no optimization): map { lc($_) => params->{$_} } keys %{params} My 3 cents, Stéphane
On Wed, Oct 6, 2010 at 8:51 AM, Stephane <stephane@shimaore.net> wrote:
"lowercase" ... in which locale?
Great perspective. My original question was whether this was intentional and to be coded around by the developer, or something that could be fixed. Your idea of making it optional is better -- maybe a config like "params_lc: 1"?
Thank you Mike for helping Dancer improve! :) On Wed, Oct 6, 2010 at 4:57 PM, Mike Schroeder <mike@donor.com> wrote:
On Wed, Oct 6, 2010 at 8:51 AM, Stephane <stephane@shimaore.net> wrote:
"lowercase" ... in which locale?
Great perspective. My original question was whether this was intentional and to be coded around by the developer, or something that could be fixed. Your idea of making it optional is better -- maybe a config like "params_lc: 1"?
What I'm wondering about are two things: 1. What does the RFC(s) say? 2. How are other frameworks handling it? Perhaps there's a "favorable method" frameworks developed that we should make note of, perhaps it's just a matter of implementing the RFC. I personally clearly see the point of providing a coherent and consistent capitalization for parameters. If I were the web programmer who cannot find the parameter because the web developer put in '<input type="hidden" name="naMe" value="zzz" />' - I'd be pretty pissed. Sawyer.
On Wed, Oct 6, 2010 at 9:07 AM, sawyer x <xsawyerx@gmail.com> wrote:
What I'm wondering about are two things: 1. What does the RFC(s) say?
http://tools.ietf.org/html/rfc3986#section-6.2.3 Certain parts of the URI have to be lowercased, or preserve case sensitivity, but in my searching so far, I haven't found anything explicitly about the param key names. This quote from the RFC seems to imply it is discretionary: Some schemes define additional subcomponents that consist of case-insensitive data, giving an implicit license to normalizers to convert this data to a common case (e.g., all lowercase).
2. How are other frameworks handling it?
Not directly related to params, catalyst is case insensitive by default: http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7012/lib/Catalyst.pm#CAS... I believe that webgui.org is case-insensitive Ruby on Rails has decided to be case sensitive, but the maintainer has not told anyone why he decided that: https://rails.lighthouseapp.com/projects/8994/tickets/393-routes-are-case-se... URI should be case sensitive by default. It *might* be nice to give option to make them insenitive though. Thanks. Without spending a lot more time researching, it would seem like the correct approach is: 1) case sensitive by default 2) case insensitive by config My two cents. Mike.
On Wed, Oct 6, 2010 at 11:22 AM, Mike Schroeder <mike@donor.com> wrote:
On Wed, Oct 6, 2010 at 9:07 AM, sawyer x <xsawyerx@gmail.com> wrote:
What I'm wondering about are two things: 1. What does the RFC(s) say?
http://tools.ietf.org/html/rfc3986#section-6.2.3 Certain parts of the URI have to be lowercased, or preserve case sensitivity, but in my searching so far, I haven't found anything explicitly about the param key names. This quote from the RFC seems to imply it is discretionary:
Some schemes define additional subcomponents that consist of case-insensitive data, giving an implicit license to normalizers to convert this data to a common case (e.g., all lowercase).
2. How are other frameworks handling it?
Not directly related to params, catalyst is case insensitive by default:
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7012/lib/Catalyst.pm#CAS...
I believe that webgui.org is case-insensitive Ruby on Rails has decided to be case sensitive, but the maintainer has not told anyone why he decided that:
https://rails.lighthouseapp.com/projects/8994/tickets/393-routes-are-case-se...
URI should be case sensitive by default. It might be nice to give option to make them insenitive though.
Thanks.
Without spending a lot more time researching, it would seem like the correct approach is: 1) case sensitive by default 2) case insensitive by config
+1
My two cents. Mike. _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================
1. What does the RFC(s) say?
I suspect this is (one of) the reference: http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.3... (I'd expect things like case-sensitivity(?) to be framework decision rather than a protocol / specification decision, though.)
2. How are other frameworks handling it?
CGI.pm is case-sensitive ;)
Without spending a lot more time researching, it would seem like the correct approach is: 1) case sensitive by default 2) case insensitive by config
Agreed. I was going to suggest that the "params_lc" option (mentioned earlier) could be a boolean or a CODE ref so that people can do fancy transforms (including locale-dependent ones) if they'd like. S.
On 6 October 2010 19:18, Stephane <stephane@shimaore.net> wrote:
1. What does the RFC(s) say?
I suspect this is (one of) the reference:
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.3...
(I'd expect things like case-sensitivity(?) to be framework decision rather than a protocol / specification decision, though.)
2. How are other frameworks handling it?
CGI.pm is case-sensitive ;)
Without spending a lot more time researching, it would seem like the
correct approach is: 1) case sensitive by default 2) case insensitive by config
Agreed.
I was going to suggest that the "params_lc" option (mentioned earlier) could be a boolean or a CODE ref so that people can do fancy transforms (including locale-dependent ones) if they'd like.
In this case, "params_lc" would be a bad name. What about "params_normalization" or something similar, that can accept either 'uppercase', 'lowercase', or a code reference? Also, some people may want to normalize the params only in some part of the application. Do we want to handle that ?
Le 07/10/2010 10:04, damien krotkine a écrit :
In this case, "params_lc" would be a bad name. What about "params_normalization" or something similar, that can accept either 'uppercase', 'lowercase', or a code reference?
Also, some people may want to normalize the params only in some part of the application. Do we want to handle that ?
I agree with Damien, and am not sure if this kind of feature should be provided by Dancer's core. We should be careful not to implement all features we may think of. I understand this can be useful in some cases, for some purposes. But we don't want Dancer to hanlde every possible cases, natively. We're a micro-framework, remember? So my suggestion would be to provide a plugin for that. Like Dancer::Plugin::Params::Normalization. If someone wants to start working on that plugin, I'd be happy to help, but my priority (as well as Franck's) is to finish 1.2 and we have still some issues to solve. Regards, -- Alexis Sukrieh
On Thursday 07 October 2010 09:11:11 Alexis Sukrieh wrote:
We should be careful not to implement all features we may think of. I understand this can be useful in some cases, for some purposes. But we don't want Dancer to hanlde every possible cases, natively.
We're a micro-framework, remember?
So my suggestion would be to provide a plugin for that. Like Dancer::Plugin::Params::Normalization.
I agree entirely. Having a very small and efficient core, and the ability to add extra features via plugins, is very useful. It could be argued that we could ship a set of "core plugins" by default so that extra features are available out of the box but not enabled/loaded unless needed, but I'm not sure even that is a good idea. <random offtopicness> On a note unrelated to Dancer, but related to modern Perl, I discovered "The Lacuna Expanse" earlier - an MMOG whose backend is all written in Perl. Excellent advert for modern Perl :) It's at www.lacunaexpanse.com </random offtopicness> -- David Precious <davidp@preshweb.co.uk> http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On 7 October 2010 10:11, Alexis Sukrieh <sukria@sukria.net> wrote:
Le 07/10/2010 10:04, damien krotkine a écrit :
In this case, "params_lc" would be a bad name. What about
"params_normalization" or something similar, that can accept either 'uppercase', 'lowercase', or a code reference?
Also, some people may want to normalize the params only in some part of the application. Do we want to handle that ?
I agree with Damien, and am not sure if this kind of feature should be provided by Dancer's core.
We should be careful not to implement all features we may think of. I understand this can be useful in some cases, for some purposes. But we don't want Dancer to hanlde every possible cases, natively.
We're a micro-framework, remember?
So my suggestion would be to provide a plugin for that. Like Dancer::Plugin::Params::Normalization.
I'm on it.
If someone wants to start working on that plugin, I'd be happy to help, but my priority (as well as Franck's) is to finish 1.2 and we have still some issues to solve.
Regards,
-- Alexis Sukrieh
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Thu, Oct 7, 2010 at 6:38 AM, damien krotkine <dkrotkine@gmail.com> wrote:
On 7 October 2010 10:11, Alexis Sukrieh <sukria@sukria.net> wrote:
We're a micro-framework, remember?
I am thrilled to see your commitment to architectural consistency and simplicity - it gives me confidence that Dancer will not bloat into something unusable.
So my suggestion would be to provide a plugin for that. Like Dancer::Plugin::Params::Normalization.
I'm on it.
You guys are amazing - you have a great team. I just sent a little donation via the paypal button for the next time you guys get together for drinks. Thanks again for dancer. Mike.
Le 07/10/2010 15:51, Mike Schroeder a écrit :
We're a micro-framework, remember?
I am thrilled to see your commitment to architectural consistency and simplicity - it gives me confidence that Dancer will not bloat into something unusable.
Indeed, this is a major target: making sure Dancer will remain a micro-framework.
You guys are amazing - you have a great team. I just sent a little donation via the paypal button for the next time you guys get together for drinks.
Thanks a lot! FYI This money will be used to print some T-shirts as soon as 1.2 is released. Regards, -- Alexis Sukrieh
I'm replying to the end of the thread, but it's meant to be a reply to all. Stephane, Mike: great research! It appears as though we've hit a gray area in the RFC between desired implied behavior and preferred explicit abilities. On Thu, Oct 7, 2010 at 10:04 AM, damien krotkine <dkrotkine@gmail.com>wrote:
On 6 October 2010 19:18, Stephane <stephane@shimaore.net> wrote:
Without spending a lot more time researching, it would seem like the
correct approach is: 1) case sensitive by default 2) case insensitive by config
Agreed.
I agree we should be case sensitive by default and by explicit request we could normalize stuff.
I was going to suggest that the "params_lc" option (mentioned earlier) could be a boolean or a CODE ref so that people can do fancy transforms (including locale-dependent ones) if they'd like.
In this case, "params_lc" would be a bad name. What about "params_normalization" or something similar, that can accept either 'uppercase', 'lowercase', or a code reference?
Naming methodologies are a pet peeve of mine. I don't like long names (when they aren't necessary) and I want it to be easy to find. Unfortunately "params_lc" isn't very clear, and "params_normalization" (via Dancer::Plugin::ParameterNormalization) seems like too much. I suggest first having the code to implement it, then deciding on a name. If the code is succinct enough, there's a chance to get it in core and not as a plugin. Generally, I would suggest integrating it if it's implemented cleanly.
Also, some people may want to normalize the params only in some part of the application. Do we want to handle that?
I don't think we should. I suggest being as straight as possible. Even though we're flexible (and that's awesome), we still want a coherent and (most importantly) a consistent behavior. If it's lowercased, it's lowercased. If it's not normalized, it's not. S.
Le 07/10/2010 10:22, sawyer x a écrit :
I suggest first having the code to implement it, then deciding on a name. If the code is succinct enough, there's a chance to get it in core and not as a plugin. Generally, I would suggest integrating it if it's implemented cleanly.
To me, it's not a question of how succint and clean the code is. It's about the fact that Dancer is supposed to be a minimalist framework, that provides the obvious and nothing more. Plugins have been made to workaround the lack of feature of the core, and I think this is why so many people like Dancer; it stays out of the way. If we start implementing _in the core_ all this kinds of details, we're taking a path where we don't want to go, trust me. Even the core "ajax" keyword has been migrated to a plugin recently, for that very same reason. I really think this normalization stuff (which relies a lot on the developer's preferences and the direction of the wind) belongs to Plugin-land. Regards, -- Alexis Sukrieh
This kind of normalisation is discouraged by the standard - I'm referring to http://tools.ietf.org/html/rfc2616#section-3.2.3 - because of the SHOULD: --- cut here --- When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of "/". Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html --- cut here --- It does not include the query part in the exceptions, hence I think that the case... SHOULD be preserved. Cheers, Flavio. On Wed, Oct 6, 2010 at 4:14 PM, Mike Schroeder <mike@donor.com> wrote:
When Dancer::Request::_parse_get_params() parses the QUERY_STRING (as I assume the post body), it leaves the key names in whatever case they come in as. I checked some RFCs (http://tools.ietf.org/html/rfc3986#section-6.2.3) to see if there was anything definitive, but not really that I could find.
From a pragmatic perspective, it would be nice to have the keys forced to lowercase by Dancer::Request. If you control every link to your application, then you can do this yourself, but if you have links coming in from external sites, and someone chooses to link to your site as
http://www.example.com/?MyPaRAM=Whatever
then simple code in Dancer expecting to see params->{myparam} will silently fail. Is this intentional behavior that I need to code around in my app, or something that could be fixed in Dancer::Request?
Thanks in advance,
Mike.
PS: Does anyone know of a good way to search the archives for this list other than using a site: param on google?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Thu, Oct 7, 2010 at 5:20 PM, Flavio Poletti <polettix@gmail.com> wrote:
This kind of normalisation is discouraged by the standard - I'm referring to http://tools.ietf.org/html/rfc2616#section-3.2.3 - because of the SHOULD:
Thank you, Flavio, for making the definitive research on this. Good luck with the plugin, Damien. And thank you Mike for raising this issue, we've all got a better understand of this now. :) Sawyer.
Hello again, I've implemented the parameters normalization plugin here : http://github.com/dams/Dancer-Plugin-Params-Normalization The route filtering isn't implemented yet as it seems difficult for a plugin to retrieve the path that matched. I failed at writing proper tests : I don't know how to set the configuration of a plugin programmatically in a test file (see 02_test_normalization.t ) Any hint appreciated. Don't hesitate to comment on the features, configuration name, and the code. dams On 8 October 2010 16:46, sawyer x <xsawyerx@gmail.com> wrote:
On Thu, Oct 7, 2010 at 5:20 PM, Flavio Poletti <polettix@gmail.com> wrote:
This kind of normalisation is discouraged by the standard - I'm referring to http://tools.ietf.org/html/rfc2616#section-3.2.3 - because of the SHOULD:
Thank you, Flavio, for making the definitive research on this.
Good luck with the plugin, Damien.
And thank you Mike for raising this issue, we've all got a better understand of this now. :)
Sawyer.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (8)
-
Alexis Sukrieh -
damien krotkine -
David Precious -
Flavio Poletti -
Mike Schroeder -
P Kishor -
sawyer x -
Stephane