Hi,

Two questions:

Google seems to indicate that IIS does not have a DOCUMENT_ROOT
equivalent. Is that indeed true? Are there workarounds besides
manually adding that environmental variable (which is kind of out of
the question in this case...)?

My problem is that I need to know that information so that I can do
some local file system operations via a CGI. One other way of getting
that information is by telling users to locate the CGI in the document
root. Is that bad practice in IIS? I know that in Apache you probably
wouldn't want to do that...you'd put your CGI in a cgi-bin directory.

Any appreciated,
Thanks,
Dave

davidnwelton@gmail.com <davidnwelton@gmail.com> wrote:

> Hi,
>
> Two questions:
>
> Google seems to indicate that IIS does not have a DOCUMENT_ROOT
> equivalent. Is that indeed true? Are there workarounds besides
> manually adding that environmental variable (which is kind of out of
> the question in this case...)?
>
> My problem is that I need to know that information so that I can do
> some local file system operations via a CGI.

Environment variables available to perl include: PATH_TRANSLATED - which
probably gives you sufficient info to calc the root.

> One other way of getting
> that information is by telling users to locate the CGI in the document
> root. Is that bad practice in IIS? I know that in Apache you probably
> wouldn't want to do that...you'd put your CGI in a cgi-bin directory.

IIS doesn't have the concept of a cgi-bin, although many programmers
create one, it isn't necessary - you can place your scripts wherever is
most convenient/logical in the context of your app.

I know of no reason why it would be bad practice to place perl scripts in
the site root.

--
William Tasso

On Wed, 31 Aug 2005, William Tasso wrote:

> IIS doesn't have the concept of a cgi-bin, although many programmers
> create one, it isn't necessary - you can place your scripts wherever
> is most convenient/logical in the context of your app.

Just for the record, you /can/ do the same with Apache if you want to.

> I know of no reason why it would be bad practice to place perl
> scripts in the site root.

In Apache, if you're not careful when you do this, it's possible
to accidentally serve-out the source code of your script instead of
executing it. That could be rather interesting to an intruder...

The benefit of having a script-aliased directory in Apache (of which
"cgi-bin" is the archetypical example), is that whatever you put in
there, Apache will try to execute it: if it is a script, then that
should be successful; if, for some reason, it's not a script, then
there will be an error reported; but the file contents will never be
served out as source code, from such a directory. This can be a
useful security measure.

But there's no need to follow that plan in Apache if you don't wish
to.

I don't know IIS myself, so I couldn't say whether it would be
possible to do anything similar with it.

best

Alan J. Flavell <flavell@ph.gla.ac.uk> wrote:

> On Wed, 31 Aug 2005, William Tasso wrote:
>
>> IIS doesn't have the concept of a cgi-bin, although many programmers
>> create one, it isn't necessary - you can place your scripts wherever
>> is most convenient/logical in the context of your app.
>
> Just for the record, you /can/ do the same with Apache if you want to.

Aha - thanks for the note - didn't know that, but that does make sense.

>> I know of no reason why it would be bad practice to place perl
>> scripts in the site root.
>
> In Apache, if you're not careful when you do this, it's possible
> to accidentally serve-out the source code of your script instead of
> executing it. That could be rather interesting to an intruder...

Aye, and that behaviour is indeed possible with IIS - but hard to achieve
accidently. File types (extention name) are mapped to processes (either
at server or site level) so any undesired behaviour should be discovered
at configuration time.

> The benefit of having a script-aliased directory in Apache (of which
> "cgi-bin" is the archetypical example), is that whatever you put in
> there, Apache will try to execute it: if it is a script, then that
> should be successful; if, for some reason, it's not a script, then
> there will be an error reported; but the file contents will never be
> served out as source code, from such a directory. This can be a
> useful security measure.

Understood.

> But there's no need to follow that plan in Apache if you don't wish
> to.
>
> I don't know IIS myself, so I couldn't say whether it would be
> possible to do anything similar with it.

I've never tried, but it is possible to set directory security such that
files can only be executed by the IIS anonymous user, rather than read.

--
William Tasso