Re: [Catalyst] Re: decoding in core (Was: [Announce] Catalyst-Runtime-5.8000_05)
On 6 Feb 2009, at 17:36, Bill Moseley wrote: Sure. IIRC, I think there's already been some patches and code posted so maybe I can dig that up again off the archives. Please do. But, sounds like it's not that important of an issue. The fact that nobody is working on it currently is not an indication that it isn't an important problem to try to solve. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: decoding in core (Was: [Announce] Catalyst-Runtime-5.8000_05)
On 6 Feb 2009, at 14:46, Bill Moseley wrote: Nobody responded to the main point of this email -- if Catalyst should handle encoding in core instead of with a plugin. Nobody has an opinion about that? Or is was it just ignored -- which is often how people handle character encoding in applications. ;) Does it make a difference if its in core or in a plugin? In your original email you said that the existing plugins don't do it right.. Which is quite possibly fair criticism, however I don't see how moving the functionality into core would help the code be more correct.. Saying 'Plugin X is broken', 'Lets move Plugin X into core' doesn't sound very convincing from where I'm sat. :_) Code speaks louder than words, so if you'd like to provide some failing tests for what you think encoding _should_ be doing, that'd probably be a better basis for further discussion. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: decoding in core (Was: [Announce] Catalyst-Runtime-5.8000_05)
On Fri, Jan 30, 2009 at 11:44:57PM +0100, Aristotle Pagaltzis wrote: * Bill Moseley mose...@hank.org [2009-01-29 17:05]: Neither of the existing plugins do it correctly (IMO), as they only decode parameters leaving body_parameters as octets, and don't look at the request for the charset, IIRC. […] uri_for() rightly encodes to octets before escaping, but it always encodes to utf-8. Is it assumed that query parameters are always utf-8 or should they be decoded with the charset specified in the request? The URI should always be assumed to be UTF-8 encoded octets. The body should be decoded according to the charset declared in the header by the browser. Assume UTF-8 because that's how the application encoded the URL in the first place? Is UTF-8 specified in an RFC? I thought it URIs were defined as characters with ASCII encoding for transmitting. Nobody responded to the main point of this email -- if Catalyst should handle encoding in core instead of with a plugin. Nobody has an opinion about that? Or is was it just ignored -- which is often how people handle character encoding in applications. ;) -- Bill Moseley mose...@hank.org Sent from my iMutt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: decoding in core (Was: [Announce] Catalyst-Runtime-5.8000_05)
On Fri, Feb 06, 2009 at 03:16:14PM +, Tomas Doran wrote: On 6 Feb 2009, at 14:46, Bill Moseley wrote: Nobody responded to the main point of this email -- if Catalyst should handle encoding in core instead of with a plugin. Nobody has an opinion about that? Or is was it just ignored -- which is often how people handle character encoding in applications. ;) Does it make a difference if its in core or in a plugin? In your original email you said that the existing plugins don't do it right.. Which is quite possibly fair criticism, however I don't see how moving the functionality into core would help the code be more correct.. Saying 'Plugin X is broken', 'Lets move Plugin X into core' doesn't sound very convincing from where I'm sat. :_) Two different issues, although I would assume if you moved it into core there would be more careful consideration and discussion about how to do it. Which is why I posted -- for a discussion. The question is should encoding be a core function. A plugin works, but not everyone uses it. My argument for doing it in core is that inside Perl is character data so therefore it must be decoded at some point, and it's Catalyst (and the engines) that load the parameters. And if it's character data on the inside it has to be encoded when writing. Code speaks louder than words, so if you'd like to provide some failing tests for what you think encoding _should_ be doing, that'd probably be a better basis for further discussion. Sure. IIRC, I think there's already been some patches and code posted so maybe I can dig that up again off the archives. But, sounds like it's not that important of an issue. -- Bill Moseley mose...@hank.org Sent from my iMutt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: decoding in core (Was: [Announce] Catalyst-Runtime-5.8000_05)
* Bill Moseley mose...@hank.org [2009-01-29 17:05]: Neither of the existing plugins do it correctly (IMO), as they only decode parameters leaving body_parameters as octets, and don't look at the request for the charset, IIRC. […] uri_for() rightly encodes to octets before escaping, but it always encodes to utf-8. Is it assumed that query parameters are always utf-8 or should they be decoded with the charset specified in the request? The URI should always be assumed to be UTF-8 encoded octets. The body should be decoded according to the charset declared in the header by the browser. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
