Comments on: PHP 6 and Request Decoding http://gravitonic.com/2007/02/php-6-and-request-decoding Life, technology, and other good things Tue, 24 Aug 2010 14:52:58 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Rob http://zmievski.org/2007/02/php-6-and-request-decoding/comment-page-1#comment-626 Rob Sun, 27 Jan 2008 11:02:23 +0000 http://www.gravitonic.com/n/?p=360#comment-626 Hello, I use IIS and I have decoding problems too.. when I click on URL UTF-8 encoded, resulting querystring replace any non english chars with question marks. Why? I usa UTF-8 encoding in my pages !!! Thank you Hello,
I use IIS and I have decoding problems too..
when I click on URL UTF-8 encoded, resulting querystring replace any non english chars with question marks. Why? I usa UTF-8 encoding in my pages !!! Thank you

]]> By: Andrei http://zmievski.org/2007/02/php-6-and-request-decoding/comment-page-1#comment-625 Andrei Thu, 22 Feb 2007 16:16:08 +0000 http://www.gravitonic.com/n/?p=360#comment-625 @Basil: If the conversion happened prior to script execution, we would have to stop at the first error and set some global error flag, since we cannot meaningfully continue. With the new approach, the conversions trigger the normal PHP error handler, which does not necessarily stop. Since the error handler may be a custom user one, there are some potential problems, depending on what the user error handler does. But like I said, this is a manageable issue. @Andrew: If there are conversion problems from raw data to $_* variables, the conversion error handler will be invoked. The application may set a custom error handler, if so desired. If you want to receive data with offending characters dropped, you can set the global error mode in your .ini file to U_CONV_ERROR_SKIP. You will be able to get at the raw data directly. We have not considered providing santizing functions like you described, but if we do, they will probably be part of ext/filter. @Basil: If the conversion happened prior to script execution, we would have to stop at the first error and set some global error flag, since we cannot meaningfully continue. With the new approach, the conversions trigger the normal PHP error handler, which does not necessarily stop. Since the error handler may be a custom user one, there are some potential problems, depending on what the user error handler does. But like I said, this is a manageable issue.

@Andrew: If there are conversion problems from raw data to $_* variables, the conversion error handler will be invoked. The application may set a custom error handler, if so desired. If you want to receive data with offending characters dropped, you can set the global error mode in your .ini file to U_CONV_ERROR_SKIP. You will be able to get at the raw data directly. We have not considered providing santizing functions like you described, but if we do, they will probably be part of ext/filter.

]]> By: Andrew Magruder http://zmievski.org/2007/02/php-6-and-request-decoding/comment-page-1#comment-624 Andrew Magruder Thu, 22 Feb 2007 14:18:08 +0000 http://www.gravitonic.com/n/?p=360#comment-624 We're experiencing this problem with PHP5.x now. What I don't understand from your proposal is how PHP handles errors and how to address those errors at the application level. I think delaying it until usage time is a good thing. I think allowing the application to specify an encoding is a good thing. But... What happens when the conversion from raw to $_ variables fails because of an invalid character encoding? How does the application find out about it? Will the application (please!) get the converted data with offending characters dropped (rather than substituted for a question mark)? Are you planning on providing some way to get at the raw data directly? (So we can build what we need if it won't be part of base-PHP.) Is there any provision for the PHP application developer to write a mapping function to replace well known problematic characters @ JIT-translation time? For example, we are routinely POSTed latin1 encoded Euro symbols in otherwise UTF-8 encoded POSTs. If suitable diagnostics are not provided by base-level PHP, the only application recourse I see, if you want to *sure* that you're doing the right thing, is rip $_ to every encoding your application might expect to deal with (about 4-5 for us) and then do string comparisons to look for missing data. Did I miss something? (I looked @ php-dev list for a bit and didn't find the answers to these questions.) We’re experiencing this problem with PHP5.x now. What I don’t understand from your proposal is how PHP handles errors and how to address those errors at the application level.

I think delaying it until usage time is a good thing. I think allowing the application to specify an encoding is a good thing.

But…

What happens when the conversion from raw to $_ variables fails because of an invalid character encoding?

How does the application find out about it?

Will the application (please!) get the converted data with offending characters dropped (rather than substituted for a question mark)?

Are you planning on providing some way to get at the raw data directly? (So we can build what we need if it won’t be part of base-PHP.)

Is there any provision for the PHP application developer to write a mapping function to replace well known problematic characters @ JIT-translation time? For example, we are routinely POSTed latin1 encoded Euro symbols in otherwise UTF-8 encoded POSTs.

If suitable diagnostics are not provided by base-level PHP, the only application recourse I see, if you want to *sure* that you’re doing the right thing, is rip $_ to every encoding your application might expect to deal with (about 4-5 for us) and then do string comparisons to look for missing data. Did I miss something? (I looked @ php-dev list for a bit and didn’t find the answers to these questions.)

]]> By: Basil Gohar http://zmievski.org/2007/02/php-6-and-request-decoding/comment-page-1#comment-623 Basil Gohar Thu, 22 Feb 2007 13:41:33 +0000 http://www.gravitonic.com/n/?p=360#comment-623 I personally cannot find any serious flaw with this design - how do other environments handle dealing with Unicode? Do they even parse incoming request incoming request information, or do they just allow runtime functions to handle the decoding? Also, I am not entirely sure I understood Rasmus' concerns. Isn't the issue of bogus data present regardless of when/how the conversion process happens? Is it a security concern, such that if the errors happened prior to the JIT routine, less harm could be done? I personally cannot find any serious flaw with this design – how do other environments handle dealing with Unicode? Do they even parse incoming request incoming request information, or do they just allow runtime functions to handle the decoding?

Also, I am not entirely sure I understood Rasmus’ concerns. Isn’t the issue of bogus data present regardless of when/how the conversion process happens? Is it a security concern, such that if the errors happened prior to the JIT routine, less harm could be done?

]]>