[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference gyro::internet_toolss

Title:Internet Tools
Notice:Report ALL NETSCAPE Problems directly to kdlucas@netscape.com.rnet? Read note 448.L for beginner information.
Moderator:teco.mro.dec.com::tecotoo.mro.dec.com::mayer
Created:Fri Jun 25 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4714
Total number of notes:40609

4427.0. "Problem integrating Purveyor for NT and Verity SearchPDF" by NETRIX::"charles.monia@shr.mts.dec.com" (Charles Monia) Tue Jan 28 1997 17:34

Hi:

I've searched this conference and have not come up with
info dealing with the following, so here goes:

I'm having a problem integrating the Verity SearchPDF CGI script with
Purveyor V1.2B for NT (I'm running V4.0 on an Intel platform). On the
surface, this seems like an obvious and serious flaw in the design of the
NT version of Purveyor. So I assume I may have overlooked something.
Anyhow, I wonder if anyone others have run into this and whether
there's an obvious (and hopefully straightforward) workaround.

(Please bear with me. The explanation below is lengthy but, given the level
of aggravation, solving the problem has now become a major crusade on my
part).

According to Purveyor release notes for 1.2B, for security reasons, the
software now requires CGI's to live in a scripts subdirectory underneath
the virtual server data directory. The documentation says that the
subdirectory must have the name 'scripts' although virtual server setup
allows you to specify something different. Anyhow, because of this, it seems
that all CGI script references from HTML must include the name of this
subdirectory  -- with the result that CGI references in existing HTML
files will break.  I've done the crude test described below and it seems
like the script subdirectory must indeed be specified.

To see what was going on, I modified an HTML by replacing the original CGI
reference with a .bat file that generated random ascii output whenever
it was run. The results indicated that the server could not find the .bat
file unless the script subdirectory was included in the path name.

From that, I concluded all CGI path specs in preexisting HTML must
be changed. Unfortunately, the SearchPDF kit has the original verity
path name sprinkled through all its HTMLs. What's worse is that HTMLs
containing this path name are generated on the fly. So, that also means
tracking down references in configuration files and templates (and hoping
some piece of software doen't have the name hardwired).

Unless I've botched things up (very possible) It's not clear to me why
Purveyor
didn't avoid the problem by implicitely 'prepending' the script subdirectory
name to such references.  Since the problem and fix are so obvious, I'm
assuming
(hoping) I missed something here.  If I haven't, then I consider this to
be a serious flaw in the design.  Since we're peddling this stuff, I thought
it would be useful to bring this to someone's attention.

FWIW:  When I called the Process Software support line I was told they'd
received a call from Verity indicating they had a similar
installation problem with SearchPDF.

Thanks for following all this,
Charles

[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name		DateLines
4427.1teco.mro.dec.com::tecotoo.mro.dec.com::mayerDanny MayerWed Jan 29 1997 08:545
	Can you provide a few example URL's and paths so we can understand
  exactly what you are seeing?  Also what are the settings in your virtual
  server page in the CPL?

		Danny
4427.2Informatiom you asked for.....STARCH::cmonia.shr.dec.com::moniaemail: STARCH::MONIATue Feb 11 1997 10:1456
Hi:

Sorry for the long delay in replying.  Other priorities got in the 
way.

The following are the virtual server settings:

Virtual Server: Default
Data Directory:	c:\win32app\purveyor
Default Filename: default.htm
Realm Name:	Default
Description:	The Default Server

Permit directory browsing:	ON
Disable basic authentication:	OFF
Disable CGI Execution:		OFF
CGI Scripts Directory:		scripts

To test the CGI path name problem, I placed the following .bat file 
in <purveyor data directory>/scripts/vcgi-bin

Test batch file topicpdf.bat

echo hello

I then started the netscape V3.0 browser. In response to the 
following url:

http://localhost/vcgi-bin/topicpdf.bat?Cmd=Admin

I received:

"The requested URL was not found

HTTP status code: 404"

After modifying the url to:

http://localhost/scripts/vcgi-bin/topicpdf.bat?Cmd=Admin

The response was:

"C:\WIN32APP\PSC\PURVEYOR>echo hello hello"

This at least seems to indicate that URL's have to be modified
to make an explicit reference to the /scripts subdirectory.

Other approaches, such as specifying a null script directory in 
virtual server setup, don't work.


Thanks,
Charles
4427.3teco.mro.dec.com::tecotoo.mro.dec.com::mayerDanny MayerTue Feb 11 1997 11:1219
> http://localhost/vcgi-bin/topicpdf.bat?Cmd=Admin

	This cannot work as vcgi-bin is not under the root and the server is
  correctly responding that it can't find it.

> http://localhost/scripts/vcgi-bin/topicpdf.bat?Cmd=Admin

	This is correct since your bat file is in a directory underneath
  the scripts directory which is under the root.  I have no idea what you
  are trying to do, but if you want the first one to work, make the CGI scripts
  directory vcgi-bin and place the bat file in a directory named vcgi-bin
  underneath the root.  If you had merely placed your bat file in the scripts
  directory and made the URL:

http://localhost/scripts/topicpdf.bat?Cmd=Admin

  it would also work without changing the configuration.

		Danny
4427.4Follow-up information you requestedSTARCH::cmonia.shr.dec.com::moniaemail: STARCH::MONIATue Feb 11 1997 14:4657
Hi Danny:

Thanks for the prompt reply.


>> http://localhost/vcgi-bin/topicpdf.bat?Cmd=Admin
> 
>        This cannot work as vcgi-bin is not under the root and the server is
>  correctly responding that it can't find it.
> 

As you suggested, I tried creating vcgi-bin under the root directory. In 
reponse to the following URL:

http://localhost/vcgi-bin/topicpdf.bat?cmd=admin

I received:

"The database does not exist 

Sorry, an error has occurred in the WAIS index search."
  
[Please note, the Purveyor scripts directory comes with a WAIS search CGI in 
one of its subdirectories. It looks to me like Purveyor has some sort of 
default which implicitely invokes this CGI under certain conditions.]


>> http://localhost/scripts/vcgi-bin/topicpdf.bat?Cmd=Admin
> 
>  This is correct since your bat file is in a directory underneath
>  the scripts directory which is under the root.  I have no idea what you
>  are trying to do, but if you want the first one to work, make the CGI
>  scripts directory vcgi-bin and place the bat file in a directory
>  named vcgi-bin underneath the root.

Easier said than done.   "scripts" is the only name accepted by the virtual 
server control panel.  Anything else you type is ignored.

>  If you had merely placed your bat file in the scripts directory and made
> the URL:
> 
> http://localhost/scripts/topicpdf.bat?Cmd=Admin
> 
>  it would also work without changing the configuration.
> 

Again, easier said than done. As I mentioned in the base note, what started 
all this is the fact that the verity search tool I'm trying to integrate has a 
CGI that's hardwired to generate other CGI urls with predefined, fixed path 
names.

I think all this is obscuring the major issue, which is the Purveyor change in 
1.2b requiring use of the scripts path in all CGI urls.  This  simply breaks a 
lot of existing html. To me, this looks more and more like a major blunder.

Thanks,
Charles
4427.5teco.mro.dec.com::tecotoo.mro.dec.com::mayerDanny MayerTue Feb 11 1997 15:246
	You'll need to contact Process Software directly about this.  I
  can't help you further since it would be basically just being an intermediary
  and I'd be talking to the same people.  If you don't get satisfaction, I
  do have people I can contact and pressure.

		Danny
4427.6Looks like a purveyor design flawSTARCH::cmonia.shr.dec.com::moniaemail: STARCH::MONIATue Feb 11 1997 17:1922
Hi Danny:

Prior to writing the base note, I contacted someone in Process 
Software product support and was told the following:

1.  There's no way around the CGI pathname requirement for script 
access.

2.  Verity has reported the same problem to Process Software.

Since I am new to all this, I continued to assume that the problem 
might have been mine or that there might be a workaround.  Given your 
response and that from Process Software support,  I'm convinced this 
is a Purveyor design flaw.

At this point, I'm less concerned about the problem as it effects me, 
than I am about bringing this bug to someone's attention within 
Digital.

Thanks for your help.
Charles
4427.7End of the line....STARCH::cmonia.shr.dec.com::moniaemail: STARCH::MONIAFri Feb 21 1997 13:2421
Hi:

Just to close this issue:

We tried all the previous suggestions and then some, none of which 
have worked. The only clue at this point is the fact that the 
verity-supplied cgi file generates good output if invoked from a 
command line and does not generate anything if invoked from the Web 
server. 

We even tried explicitely setting up the HTTP environment 
variables in the .bat version.  Result:  Same behavior as described 
above.
 
FWIW: We've also tried the Purveyor Visual Basic wraparound fix for 
buffered CGI and that has not helped.  Anyhow, we're now looking for 
an alternate solution -- new web server or pdf search tool.  I've 
opened that as a seperate topic.

Thanks for the help.
Charles