Comments for RuslanY Blog http://ruslany.net IIS, FastCGI, PHP and other interesting stuff Fri, 05 Dec 2008 00:12:06 +0000 http://wordpress.org/?v=2.6.2 Comment on ASP.NET postbacks and URL rewriting by ruslany http://ruslany.net/2008/10/aspnet-postbacks-and-url-rewriting/#comment-93 ruslany Wed, 12 Nov 2008 03:00:28 +0000 http://ruslany.net/2008/10/aspnet-postbacks-and-url-rewriting/#comment-93 More information about URL rewriting for ASP.NET web forms is available here: http://learn.iis.net/page.aspx/517/url-rewriting-for-aspnet-web-forms/ More information about URL rewriting for ASP.NET web forms is available here: http://learn.iis.net/page.aspx/517/url-rewriting-for-aspnet-web-forms/

]]> Comment on URL Rewrite Module - Go Live release by RuslanY Blog http://ruslany.net/2008/09/url-rewrite-module-go-live-release/#comment-92 RuslanY Blog Mon, 10 Nov 2008 22:32:35 +0000 http://ruslany.net/2008/09/url-rewrite-module-go-live-release/#comment-92 <strong>URL Rewrite Module - Release to Web...</strong> Today IIS team has made the URL Rewrite Module for IIS 7.0 Release To Web (RTW) available for download. This is a final, production-ready release that is officially supported by Microsoft. Install the URL Rewrite Module for IIS 7.0 RTW today! Microsoft... URL Rewrite Module - Release to Web…

Today IIS team has made the URL Rewrite Module for IIS 7.0 Release To Web (RTW) available for download. This is a final, production-ready release that is officially supported by Microsoft.
Install the URL Rewrite Module for IIS 7.0 RTW today!
Microsoft…

]]> Comment on Major revision of FastCGI/PHP article on IIS.NET by ruslany http://ruslany.net/2008/10/major-revision-of-fastcgiphp-article-on-iisnet/#comment-90 ruslany Thu, 06 Nov 2008 06:28:04 +0000 http://ruslany.net/2008/10/major-revision-of-fastcgiphp-article-on-iisnet/#comment-90 For MaxInstances there is no technical reason for the difference in defaults. One value is not better than the other. For development purposes either of the defaults would work fine. For production deployment you would probably need to fine tune this number anyway to achieve full CPU load. For MaxInstances there is no technical reason for the difference in defaults. One value is not better than the other. For development purposes either of the defaults would work fine. For production deployment you would probably need to fine tune this number anyway to achieve full CPU load.

]]> Comment on Update for IIS 7.0 FastCGI module by ruslany http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-88 ruslany Wed, 05 Nov 2008 20:01:49 +0000 http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-88 If the Default.aspx is located in /office-monkey/Default.aspx then yes, they need to install the update. After the update is applied FastCGI module will use the URL path from CACHE_URL server variable to set the REQUEST_URI. If the Default.aspx is located in /office-monkey/Default.aspx then yes, they need to install the update. After the update is applied FastCGI module will use the URL path from CACHE_URL server variable to set the REQUEST_URI.

]]> Comment on Update for IIS 7.0 FastCGI module by Andrew http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-87 Andrew Wed, 05 Nov 2008 19:56:04 +0000 http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-87 Thanks for the help, Ruslan. I created and placed a ASPX page that sets a Label to Request.ServerVariables("CACHE_URL"). The value that is set is "http://www.office-monkey.com:80:72.167.131.48/Default.aspx". From all of this, it sounds like my assumption that my hosting provider needs to install the FastCGI update -- is that correct? (I need a clear statement that I can take to the tech support people. :-)) Thank you! Thanks for the help, Ruslan.

I created and placed a ASPX page that sets a Label to Request.ServerVariables(”CACHE_URL”). The value that is set is “http://www.office-monkey.com:80:72.167.131.48/Default.aspx”.

From all of this, it sounds like my assumption that my hosting provider needs to install the FastCGI update — is that correct? (I need a clear statement that I can take to the tech support people. :-))

Thank you!

]]> Comment on Update for IIS 7.0 FastCGI module by ruslany http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-86 ruslany Wed, 05 Nov 2008 19:31:53 +0000 http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-86 It looks like GoDaddy uses some sort of URL rewriting for this. I could think of couple of ways to validate this: 1. Try to access $_SERVER['HTTP_X_ORIGINAL_URL'] or $_SERVER['HTTP_X_REWRITE_URL']. If one of those is set then they use Microsoft URL rewrite or ISAPI_Rewrite respectively. That would mean that they do not have the FastCGI update installed, but you would be able to work it around in wordpress by doing this: $_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_ORIGINAL_URL']; 2. If none of those server vars is set then another thing to try is to print out IIS server variable CACHE_URL. Unfortunately, this variable is not accessable from PHP, so you would need to use ASP or ASPX page to print its value. If this server variable contains the http://www.office-monkey.com/default.aspx, then again it proves that the hosting provider does not have the FastCGI update installed. There is no easy workaround for this though, so you would have to ask the hosting provider to install the update. It looks like GoDaddy uses some sort of URL rewriting for this. I could think of couple of ways to validate this:

1. Try to access $_SERVER['HTTP_X_ORIGINAL_URL'] or $_SERVER['HTTP_X_REWRITE_URL']. If one of those is set then they use Microsoft URL rewrite or ISAPI_Rewrite respectively. That would mean that they do not have the FastCGI update installed, but you would be able to work it around in wordpress by doing this:
$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_ORIGINAL_URL'];

2. If none of those server vars is set then another thing to try is to print out IIS server variable CACHE_URL. Unfortunately, this variable is not accessable from PHP, so you would need to use ASP or ASPX page to print its value. If this server variable contains the http://www.office-monkey.com/default.aspx, then again it proves that the hosting provider does not have the FastCGI update installed. There is no easy workaround for this though, so you would have to ask the hosting provider to install the update.

]]> Comment on Update for IIS 7.0 FastCGI module by Andrew http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-85 Andrew Wed, 05 Nov 2008 14:55:56 +0000 http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/#comment-85 I <em>think</em> I'm running into the latter issue on GoDaddy shared IIS7 hosting, but unfortunately, I can't be sure. They're being unresponsive, so I'm hoping someone can validate that my suspicions are correct. For the latter problem: I've debugged my wordpress issue, and it's come down to this: $_SERVER['REQUEST_URI'] = '/office-monkey/index.php' when it is expected to be $_SERVER['REQUEST_URI'] = '/index.php' The client URL I start with is 'http://www.office-monkey.com/index.php', but since I'm under shared hosting, the file itself actually resides in '/office-monkey/index.php'. I believe this would match the poorly documented issue where the REQUEST_URI is set to the POST-rewrite input, rather than the pre-rewrite input, but I can't find validation, and don't have access to a standalone IIS server to validate. Can anyone help? I think I’m running into the latter issue on GoDaddy shared IIS7 hosting, but unfortunately, I can’t be sure. They’re being unresponsive, so I’m hoping someone can validate that my suspicions are correct.

For the latter problem: I’ve debugged my wordpress issue, and it’s come down to this:
$_SERVER['REQUEST_URI'] = ‘/office-monkey/index.php’
when it is expected to be
$_SERVER['REQUEST_URI'] = ‘/index.php’

The client URL I start with is ‘http://www.office-monkey.com/index.php’, but since I’m under shared hosting, the file itself actually resides in ‘/office-monkey/index.php’. I believe this would match the poorly documented issue where the REQUEST_URI is set to the POST-rewrite input, rather than the pre-rewrite input, but I can’t find validation, and don’t have access to a standalone IIS server to validate.

Can anyone help?

]]> Comment on Major revision of FastCGI/PHP article on IIS.NET by Franklin Tse http://ruslany.net/2008/10/major-revision-of-fastcgiphp-article-on-iisnet/#comment-84 Franklin Tse Wed, 05 Nov 2008 02:13:36 +0000 http://ruslany.net/2008/10/major-revision-of-fastcgiphp-article-on-iisnet/#comment-84 Thanks! However, besides the InstanceMaxRequests, the MaxInstances default has also been changed from 10 to 4. Is 4 better than 10? Thanks! However, besides the InstanceMaxRequests, the MaxInstances default has also been changed from 10 to 4. Is 4 better than 10?

]]> Comment on Ruby on Rails in IIS 7.0 with URL Rewriter by ruslany http://ruslany.net/2008/08/ruby-on-rails-in-iis-70-with-url-rewriter/#comment-83 ruslany Mon, 03 Nov 2008 18:38:52 +0000 http://ruslany.net/2008/08/ruby-on-rails-in-iis-70-with-url-rewriter/#comment-83 Awajan, I have not tried this on x64 bit. I could not find the 64bit version of Ruby, but 32bit version should work in theory, if you configure IIS application pool to enable 32-bit applications (enable32BitAppOnWin64) Awajan,

I have not tried this on x64 bit. I could not find the 64bit version of Ruby, but 32bit version should work in theory, if you configure IIS application pool to enable 32-bit applications (enable32BitAppOnWin64)

]]> Comment on ASP.NET postbacks and URL rewriting by ruslany http://ruslany.net/2008/10/aspnet-postbacks-and-url-rewriting/#comment-82 ruslany Mon, 03 Nov 2008 18:32:14 +0000 http://ruslany.net/2008/10/aspnet-postbacks-and-url-rewriting/#comment-82 prabhjot, Does your ASP.NET application use "~" symbols when constructing the URLs for the home tab? If yes, then this may be due to a bug in ASP.NET that we will fix by the time we ship RTW of the URL rewrite module. prabhjot,

Does your ASP.NET application use “~” symbols when constructing the URLs for the home tab? If yes, then this may be due to a bug in ASP.NET that we will fix by the time we ship RTW of the URL rewrite module.

]]>