Re: New Application Extension reports 404
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 09/06/04
- Next message: David Wang [Msft]: "Re: Unable to do anything with IIS on Windows XP SP2"
- Previous message: Lakshmi Narayanan.R: "Setting custorm error in IIS"
- In reply to: Jim Frankland: "New Application Extension reports 404"
- Next in thread: Ken Schaefer: "Re: New Application Extension reports 404"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 5 Sep 2004 19:59:41 -0700
The reference to web.config is a complete red herring to your current
question. Please ignore it since it is only applicable to URLs handled by
ASP.Net. You actually want .RUN to be handled by Perl, so that approach is
not workable.
... Unless you are using IIS6 and ASP.Net 2.0 (Whidbey beta). With that
combination, ASP.Net can be configured to filter all incoming URLs and
handle the ones it is configured to. Everything else is handled by the
appropriate handler (so you can actually run ASP.Net code on every single
incoming request, including Perl, and then have Perl finally parse the file
and generate the response.
Now that I have thoroughly confused you, let's get on to the actual
question. :-) There are actually a couple of valid ways to make your
situation work.
1. Using your current configuration
--> Please check the web server logfiles for the entry corresponding to your
request to the non-working scriptmap that returns a "404" response. It is
probably saying "404 2 1260". If so, please add a Web Service Extension
that looks *exactly* like the non-working scriptmap -- extensions and all --
i.e.
F:\Perl\bin\perl.exe "E:\Inetpub\myhostsite\functions\formscript.pl"
This is mostly an issue you see when using CGI EXEs and commandline
parameters because core IIS webserver does not parse the string you give for
ScriptMapping for commandline/parameters (so it doesn't know that
"F:\Perl\bin\perl.exe" is already allowed by your other
WebServiceExtension) -- the Win32 CreateProcessAsUser call will parse the
parameters when it runs it.
2. If you need different commands mapped to non-existent files in the same
directory, i.e.
/command1.run will execute Perl script1.pl
/command2.run will execute Perl script2.pl
This isn't easily configurable via the UI. Use ADSUTIL.VBS to directly
change the IIS configuration -- assuming you are running website ID1
(default website).
cscript ADSUTIL.VBS CREATE W3SVC/1/root/command1.run IIsWebFile
cscript ADSUTIL.VBS SET W3SVC/1/root/command1.run/ScriptMaps .run,Perl
script1.pl,1
cscript ADSUTIL.VBS CREATE W3SVC/1/root/command2.run IIsWebFile
cscript ADSUTIL.VBS SET W3SVC/1/root/command2.run/ScriptMaps .run,Perl
script2.pl,1
And add separate WebServiceExtensions for "Perl script1.pl" and "Perl
script2.pl"
Conceptually, what these approaches do is:
1. For all requests with an extension of .run , call CreateProcessAsUser
with:
F:\Perl\bin\perl.exe "E:\Inetpub\myhostsite\functions\formscript.pl"
2. For all requests to /command1.run, execute Perl script1.pl
For all requests to /command2.run, execute Perl script2.pl
Clearly, Approach #2 is very selective -- /command3.run will return a 404 as
it does not exist nor is there a scriptmap, while approach #1 will return
the response of F:\Perl\bin\perl.exe
"E:\Inetpub\myhostsite\functions\formscript.pl"
Finally -- when you change IIS configuration and it isn't behaving as you
expect, you want to look at various log files to decipher what is going on.
The key ones for IIS6 are:
1. HTTP Error Log -- connection-level timeout/disconnect/errors --
%SYSTEMROOT%\system32\logfiles\httperr
2. W3SVC Log File -- website level request execution results --
%SYSTEMROOT%\system32\logfiles\W3SVC#
3. Event Log -- catestrophic errors, unexpected server behavior/failures
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "Jim Frankland" <PRIVATEjfrankland@PRIVATEacoffice.comPRIVATE> wrote in message news:uo2i1n6kEHA.596@TK2MSFTNGP11.phx.gbl... Hi all, I'm sure I'm missing a simple security setting somewhere. Moving a site from a IIS4 server to IIS6 on W2K3. The original developer used lots of different file extensions (I assume in an attempt to deter hackers). For example he might call a form script called MYFORM.RUN or SUBMITFORM.RUN. Neither of these filenames actually exist on the server, but IIS4 had the "RUN" extension mapped to execute a predefined perl script. In IIS6 I go into my directory properties and under the DIRECTORY tab I created an Application Settings. Set it up for "Scripts and Executables" and set my Application Pool. Then I went into CONFIGURATION... Under the MAPPINGS tab I created a new extension of RUN. Under the executable path I enter: F:\Perl\bin\perl.exe "E:\Inetpub\myhostsite\functions\formscript.pl" in the executable dialog. I made sure to REMOVE the check on the box VERIFY THAT THE FILE EXISTS and limited it to GET, POST. This is VERY SIMULAR to a WORKING perl script extension of: Extension = .PL Executable = F:\Perl\bin\perl.exe "%s" %s I've tried eliminating the full path in the executable, since the formscript.pl is located in the same directory as the form html code. I've also tried ALL VERBS instead of the post/get limit. Always the same effect... The browser reports 404 "directory or file does not exist" error. I can run the formscript.pl by entering it on the browser address line, so I know it works and perl is functioning. I'm sure there is a simple setting I am missing. I saw a reference to WEB.CONFIG file in a BIN directory with code to <add verb... for <httpHandlers... but I am not fully understanding this - it might only be for ASPX? Thanks in advance for help on these extensions. (I know the simple answer may be to change all the HTM code to properly call the perl scripts directly, but in thousands of pages - I'm sure to miss something. I already have a list of all these funny extensions and executables from the IIS4 server.)
- Next message: David Wang [Msft]: "Re: Unable to do anything with IIS on Windows XP SP2"
- Previous message: Lakshmi Narayanan.R: "Setting custorm error in IIS"
- In reply to: Jim Frankland: "New Application Extension reports 404"
- Next in thread: Ken Schaefer: "Re: New Application Extension reports 404"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
