IIS 5.0 und CGIProxy 1.4.1

[Matz]

hei leute,
vielleicht könnt ihr mir helfen wäre ganial....................

ich versuche unter Win2000 und dem IIS 5.0 das CGIProxy 1.4.1 Script zum laufen zu bringen, leider hat der IIS die Eigenschaft, daß er die Path-Info falsch übermittelt

mit Apache getestet, da funktioniert das Script
Ergebnis ==> http://donpadre.dnsalias.com/cgi-bin/nph-proxy.cgi/01010/http/web.de/?id=V00-010715-*u6.p-00

unter IIS
Ergebnis ==> http://donpadre.dnsalias.com/cgi-bin/nph-proxy.cgi/01000/x-proxy/start

Es gibt auch zwei Hinweise in diesem Script die diese Problematik beschreiben, leider kann ich mit den Variablen nichts anfangen, da ich nicht der absolute "Perl-Crack" bin.
PS: Der Hersteller http://www.jmarshall.com/tools/cgiproxy/ dieses Script`s konnte mir auch nicht helfen, da er keine Erfahrung mit IIS hat.
Vielleicht müssen nur die Variablen in "sub proxy_encode"  oder "sub proxy_decode" anders gesetzt werden, denn wenn man an diesen rumspielt verändert sich das Ausgabeergebnis..... aber wie gesagt welche ??? :-)))

Vielleicht hattet ihr schon jemanden mit den selben Problemen ... oder die Lösung ist easy .........
hilfe wäre echt genial ......... bastle schon 10 Tage ...... :-)))

Hier mal als klartext:
#############################################################

Create your own proxy_encode() and proxy_decode() to tranform the target

#   URL to and from the format that will be stored in PATH_INFO.  The encoded
#   form should only contain characters that are legal in PATH_INFO.  This
#   varies by server, but using only printable chars, no "?" or "#", and no
#   two adjacent slashes ("//") works on most servers.  Don't let PATH_INFO
#   contain the strings "./", "/.", "../", or "/..", or else it may get
#   compressed like a pathname somewhere.  Try not to make the resulting
#   string too long, either.

Of course, proxy_decode() must exactly undo whatever proxy_encode() does.

Make proxy_encode() as fast as possible-- it's a major bottleneck for the

#   whole program.

Because of the simplified absolute URL resolution in full_url(), there may

#   be ".." segments in the default encoding here, notably in the first path
#   segment.  Normally, that's just an HTML mistake, but please tell me if
#   you see any privacy exploit with it.

sub proxy_encode {
    local($URL)= @_ ;
    $URL=~ s#^([\w+.-]+)://#$1/# ;                 # http://xxx -> http/xxx
#    $URL=~ s/(.)/ sprintf('%02x',ord($1)) /ge ;   # each char -> 2-hex
#    $URL=~ tr/a-zA-Z/n-za-mN-ZA-M/ ;              # rot-13
    return $URL ;
}

sub proxy_decode {
    local($PATH_INFO)= @_ ;
#    $PATH_INFO=~ tr/a-zA-Z/n-za-mN-ZA-M/ ;        # rot-13
#    $PATH_INFO=~ s/([0-9A-Fa-f]{2})/ sprintf("%c",hex($1)) /ge ;
    $PATH_INFO=~ s#^([\w+.-]+)/#$1://# ;           # http/xxx -> http://xxx
    return $PATH_INFO ;
}

#################################################################

The IIS server doesn't set PATH_INFO correctly-- it sets it to the entire

#   request URI, rather than just the part after the script name.  So fix it
#   here if we're running on IIS.  Thanks to Dave Moscovitz for the info!
if ( $RUNNING_ON_WINDOWS && ($ENV{'SERVER_SOFTWARE'}=~ /IIS/) ) {
    $ENV{'PATH_INFO'} =~ s/^$ENV{'SCRIPT_NAME'}// ;
}

#########################################################################