Skip Menu |

This queue is for tickets about the Catalyst-Runtime CPAN distribution.

Report information
The Basics
Id: 76522
Status: open
Priority: 0/
Queue: Catalyst-Runtime

People
Owner: bobtfish [...] bobtfish.net
Requestors: KnowZeroX [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 5.90011
Fixed in: (no value)



On IIS7.5 FCGI, PATH_INFO and SCRIPT_NAME seem to be the same, so the Plack CGI handler removes PATH_INFO and makes it blank. In Plack::Handler::FCGI $env->{PATH_INFO} =~ s/^\Q$env->{SCRIPT_NAME}\E//; The iis6scriptname fix seems to be useless as it relies on PATH_INFO. Though I am not sure it is even necessary anymore. All I know is with a blank PATH_INFO Catalyst does not seem to work. And under IIS 7.5 and FCGI the PATH_INFO will always be blank. I wrote a script for myself around it with no problem but it definitely needs to be patched either in Catalyst or Plack. To note I am using ActiveState Perl and have tested this in 5.12 and 5.14. (Don't know if this makes a difference in comparison to Strawberry Perl)
On Thu Apr 12 22:59:50 2012, KnowZeroX@yahoo.com wrote: Show quoted text
> it > definitely needs to be > patched either in Catalyst or Plack.
Ok - I agree we should certainly fix this, however I don't have access to an IIS 7.5 environment - can you give us a dump of the incoming ENV before Plack mangles it? Also, some additional details about what you're doing to fix it would be good. Fixing this (should be) fairly easy - however without appropriate test data, I'm going to be groping blindly in the dark, and there isn't quite enough info in this bug yet for me to be confident in writing tests for the issue. Thanks for the bug report, and thanks in advance for further assistance getting this fixed!
From: KnowZeroX [...] yahoo.com
Thanks for the quick response! On Fri Apr 13 04:18:23 2012, BOBTFISH wrote: Show quoted text
> On Thu Apr 12 22:59:50 2012, KnowZeroX@yahoo.com wrote:
> > it > > definitely needs to be > > patched either in Catalyst or Plack.
> > Ok - I agree we should certainly fix this, however I don't have access > to an IIS 7.5 environment - can you give us a dump of the incoming ENV > before Plack mangles it? >
Here are the relevant ENV variables: GET http://127.0.0.1:5000/testme/try.html PATH_INFO: /testme/try.html SCRIPT_NAME: /testme/try.html PATH_TRANSLATED: C:\Sites\Test\root\testme\try.html GET http://127.0.0.1:5000/testme/ PATH_INFO: /testme/test/ SCRIPT_NAME: /testme/test/ PATH_TRANSLATED: C:\Sites\Test\root\testme\test\ Show quoted text
> Also, some additional details about what you're doing to fix it would
be Show quoted text
> good. > > Fixing this (should be) fairly easy - however without appropriate test > data, I'm going to be groping blindly in the dark, and there isn't
quite Show quoted text
> enough info in this bug yet for me to be confident in writing tests
for Show quoted text
> the issue. > > Thanks for the bug report, and thanks in advance for further
assistance Show quoted text
> getting this fixed! >
As for my patch, I modified the FCGI handler itself with: if ($env->{SERVER_SOFTWARE} && $env->{SERVER_SOFTWARE} =~ m/IIS/ && $env->{SCRIPT_NAME} eq $env->{PATH_INFO}) { } else { $env->{PATH_INFO} =~ s/^\Q$env->{SCRIPT_NAME}\E//; } Another approach I did was just backup the PATH_INFO into PLACK_PATH_INFO and then restore it into the iis6fix middleware, that works too.
On Fri Apr 13 04:47:38 2012, KnowZeroX@yahoo.com wrote: Show quoted text
> Thanks for the quick response!
Thanks for the quick follow up! Show quoted text
> Here are the relevant ENV variables:
<snip> - thanks Show quoted text
> > Also, some additional details about what you're doing to fix it
<snip> Show quoted text
> As for my patch, I modified the FCGI handler itself with:
<snip> Thanks, that's about the info I need. Only remaining thing - as this fix behavior should probably be conditional only to newer versions of IIS - can you confirm what SERVER_SOFTWARE this should be expecting? I'm away for all this weekend - but I'll try to find time to push a branch with a possible fix on Monday or Tuesday night. Please feel free to pester if you don't hear anything for a week (as I've probably forgotten/got distracted) :)
From: KnowZeroX [...] yahoo.com
Show quoted text
> Only remaining thing - as this fix behavior should probably be > conditional only to newer versions of IIS - can you confirm what > SERVER_SOFTWARE this should be expecting?
SERVER_SOFTWARE: Microsoft-IIS/7.5 Not sure how IIS 7.0 is, but I have access to an IIS 6 instance so I am going to install a test there and see what effect it has there and get back to you. Show quoted text
> I'm away for all this weekend - but I'll try to find time to push a > branch with a possible fix on Monday or Tuesday night. > > Please feel free to pester if you don't hear anything for a week (as > I've probably forgotten/got distracted) :)
I understand, I am leaving on vacation next week myself ;), if by the time I get back I don't see a fix I'll follow up with you.
From: KnowZeroX [...] yahoo.com
Hmmm...IIS 6 seems to be behaving the same way as IIS7.5. And I used Perl 5.10 on this test. PATH_INFO: /tryme/test.html SCRIPT_NAME: /tryme/test.html PATH_TRANSLATED: C:\Sites\Test\root\tryme\test.html I guess that leaves 1 more thing to test, whether or not strawberry perl differs from activestate perl.
From: KnowZeroX [...] yahoo.com
I have ran Strawberry perl on IIS6 PATH_INFO: /testmenow/now.html SCRIPT_NAME: /testmenow/now.html PATH_TRANSLATED: C:\Sites\Test\root\testmenow\now.html Same output. By commenting out: $env->{PATH_INFO} =~ s/^\Q$env->{SCRIPT_NAME}\E//; and leaving iis6 test script running I get the following: PATH INFO: //testme/try.html SCRIPT_NAME: PATH_TRANSLATED: C:\Sites\Test\root\testme\try.html So the IIS6 script removes the script name and leaves only the path info. Which leaves me to believe that maybe the person who made the iis6 testscript may have been working on a earlier version of catalyst on their end that did not null out the PATH_INFO. Assuming what the iis6 script is doing is correct. The simplest solution seems to be: my @script_name = split(m!/!, $env->{SCRIPT_NAME}); instead of my @script_name = split(m!/!, $env->{PATH_INFO}); in the iis6 script middleware? or maybe a bit more paranoid approach of: my @script_name = split(m!/!, $env->{PATH_INFO} eq '' ? $env-> {SCRIPT_NAME}:$env->{PATH_INFO} ); This way if for some reason somewhere PATH_INFO is actually used it won't intervene with the script.
From: KnowZeroX [...] yahoo.com
Ok, I think I figured out the logic of why the IIS6ScriptNameFix is there. If I were to guess IIS6ScriptNameFix was meant for CGI and not for FCGI. So a more universal way would be the paranoid way which should work for both CGI and FCGI: my @script_name = split(m!/!, $env->{PATH_INFO} eq '' ? $env-> {SCRIPT_NAME}:$env->{PATH_INFO} ); And sorry for all the spam, I am just being very paranoid here to not break anything for anyone else lol
From: KnowZeroX [...] yahoo.com
Alight I am back, any progress on this issue? or anything else you need tested?
From: KnowZeroX [...] yahoo.com
I don't want to give any names, but someone asked me to pester you if there has been no patch within a week. So I am following up on the progress. Also would be interested to know if this is an issue with Plack or with Catalyst?
From: KnowZeroX [...] yahoo.com
Reminder #3 my $count=3; while ( !exists($bobtfish) ) { print "Reminder #".($count++); sleep( (24*60*60) ); }
Having studied it more, I think this should be fixed in Plack::Handler::FCGI - to make the slashes fix (which according to the comments is lighttpd only) only apply for lighty. https://github.com/bobtfish/Plack/tree/t0m_iis_fcgi_rt76522 I've pushed a branch for Plack with some failing tests demonstrating this..
From: KnowZeroX [...] yahoo.com
Ok, thanks a lot! Have you had a chance to look at the content-length bug? I have found it causes much more issues then I originally anticipated. People get this on redirects: Object Has Moved. This document can be found at ~~GZIPPED CONTENT~~ As you can guess that looks pretty scary to some users :/ Personally I don't understand why the "Object Has Moved" is written by catalyst. Could it be that both catalyst and IIS are writing an Object Has Moved response? I am going to look into it further myself but so far I think the best solution is to have a parameter to tick on and off catalyst writing object has moved. Tell me if you need any testing done.