Re: [INTERNALS-WIN] Question about using UTF-8 encoding for server variables used by PHP

hi Wade,

On Tue, Jan 26, 2010 at 2:03 AM, Wade Hilmo <[email protected]> wrote:

> I think that there is a difference of philosophy that is at the root of the issue here.  PHP considers decoding of the URL to be a task for the application.  IIS considers decoding of the URL to be a server function.

Not only PHP, I was refering to (F)CGI as well here.

As it could make sense (still not sure it is a good thing to do) to
use Unicode (or whatever other encoding IIS considers as the way to
go) in the IIS+asp.net combination, the idea behind the two being a
kind of full application server, even if it gets modularized in
version 7 (very good thing btw).

I can imagine it would be possible to do it if PHP was still using the
ISAPI instead of FastCGI, as we could access the internal IIS or
http.sys API directly. We could get the physical path of the file
directly as well using IHttpContext::GetPhysicalPath, or using other
valuable APIs. But we use FastCGI, there is no linking between IIS and
PHP and there are standard (more or less well documented :) for it.

Please note that for (F)CGI some variables should not be decoded
(never), as specified here
http://hoohoo.ncsa.illinois.edu/cgi/env.html

> The main reason IIS owns decoding is that the IIS core server takes some actions on the decoded URL before it even calls into application code.  The results of these actions sometimes have significant security ramifications.  Historically, there have been a number of exploited vulnerabilities that were a result of an application decoding the URL in a way that is not identical to the way that IIS decodes it.  Any change to the way that we do this would be perceived as a security risk (and based on my experience, it would eventually be exploited in some way.)

I would like to discuss the security risk more closely as I'm not
aware of any open ones to date. If you have references to past flaws
related to FastCGI and encoding, I would also like to get an eye on
them. Please drop me a mail to my msft addy so we can discuss it off
list if necessary (not willing to end the discussions here but
security issues should not be discussed here).

> Finally, getting back to Unicode APIs, the point I was trying to make about SCRIPT_FILENAME is that unless PHP uses Unicode APIs to open the script file, it will not be possible to support multiple code pages for content.  The problem is that the non-Unicode APIs do not support UTF-8 and require the path to be expressed in the default system code page.  This is not possible if the URL was encoded in some other code page, even though IIS itself can handle different code pages.

The query string should not be decoded at all (see
http://hoohoo.ncsa.illinois.edu/cgi/env.html), that leaves the script
name which works well as of now or am I missing something? Yes it
would rock to be able to use unicode filenames, but that's not
possible now and that won't be possible before the next major version.
However whether we use the unicode API or not does not solve the
problem about why IIS should suddenly use Unicode to pass the
environments to the fastcgi instances. I understand why you would like
to do it but I don't see why this change must be done.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org