netscape fastrack server and zope..?
hi zopistas here's an odd one. i've never heard of anyone running Zope with PCGI through a Netscape server, but somehow a friend of mine set it up (FastTrack 2.0.1) and now he has just one little problem. renaming an object works when he accesses the zope instance using the port ZServer listens on, but he is getting a "Not Found" error when using the netscape server port. Looking at his logs he finds that the rename operation all of a sudden tries to display the URL <server>/Zope/. (including the dot), which results in the "Not Found" Netscape server message. his rewrite rule is: NameTrans from="/Zope" fn="pfx2dir" dir="/stripe1/zope/Zope-2.0.1-src/Zope.cgi" which looks a translation of the standard example rule used to set up apache. here is a little piece of log from the server. notice the "404" in the last line: <snippers> 10.1.1.1 - - [28/Sep/1999:01:57:30 +0000] "GET /Zope/Test/manage_main HTTP/1.0" 200 5472 0.835 10.1.1.1 - - [28/Sep/1999:01:57:30 +0000] "GET /Zope/p_/ltab HTTP/1.0" 200 88 0.570 10.1.1.1 - - [28/Sep/1999:01:57:37 +0000] "POST /Zope HTTP/1.0" 401 1494 0.529 10.1.1.1 - - [28/Sep/1999:01:57:38 +0000] "POST /Zope HTTP/1.0" 200 891 0.589 10.1.1.1 - - [28/Sep/1999:01:57:43 +0000] "POST /Zope/. HTTP/1.0" 404 247 0.550 </snippers> is anyone here actually using the FastTrack server and could spot the problem? any help greatly appreciated :) jens Jens Vagelpohl Systems Administrator Washtenaw Development Council
Jens Vagelpohl wrote:
hi zopistas
here's an odd one. i've never heard of anyone running Zope with PCGI through a Netscape server, but somehow a friend of mine set it up (FastTrack 2.0.1) and now he has just one little problem.
renaming an object works when he accesses the zope instance using the port ZServer listens on, but he is getting a "Not Found" error when using the netscape server port. Looking at his logs he finds that the rename operation all of a sudden tries to display the URL <server>/Zope/. (including the dot), which results in the "Not Found" Netscape server message.
his rewrite rule is:
NameTrans from="/Zope" fn="pfx2dir" dir="/stripe1/zope/Zope-2.0.1-src/Zope.cgi"
which looks a translation of the standard example rule used to set up apache.
here is a little piece of log from the server. notice the "404" in the last line:
<snippers> 10.1.1.1 - - [28/Sep/1999:01:57:30 +0000] "GET /Zope/Test/manage_main HTTP/1.0" 200 5472 0.835 10.1.1.1 - - [28/Sep/1999:01:57:30 +0000] "GET /Zope/p_/ltab HTTP/1.0" 200 88 0.570 10.1.1.1 - - [28/Sep/1999:01:57:37 +0000] "POST /Zope HTTP/1.0" 401 1494 0.529 10.1.1.1 - - [28/Sep/1999:01:57:38 +0000] "POST /Zope HTTP/1.0" 200 891 0.589 10.1.1.1 - - [28/Sep/1999:01:57:43 +0000] "POST /Zope/. HTTP/1.0" 404 247 0.550 </snippers>
This is because Netscape, incorrectly, prevents a request from acessing the '.' "document" in a folder (which should be the folder itself). Using '.' is not a violation of the HTTP spec, and every other web server i've used handles it properly. You can fix this by changing all ocurances of '.' in Zope's DTML source with URL1 -Michel
is anyone here actually using the FastTrack server and could spot the problem?
any help greatly appreciated :)
jens
Jens Vagelpohl
Systems Administrator Washtenaw Development Council
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Michel Pelletier wrote:
Jens Vagelpohl wrote:
[Log snipped] 10.1.1.1 - - [28/Sep/1999:01:57:43 +0000] "POST /Zope/. HTTP/1.0" 404 247 0.550 </snippers>
This is because Netscape, incorrectly, prevents a request from acessing the '.' "document" in a folder (which should be the folder itself).
Using '.' is not a violation of the HTTP spec, and every other web server i've used handles it properly.
You can fix this by changing all ocurances of '.' in Zope's DTML source with URL1
Since that sounds so extreme, here's a patch to nscgi-auth.c instead which strips /. from the end of URLs. Add the parameter stripdot=1 to the NameTrans fn="cgiauth-nametrans" function, e.g. NameTrans fn="cgiauth-nametrans" stripdot=1 I hereby assign all rights to this patch to Digitial Creations provided I am waived of all warranty requirements, requirements of fitness for a particular purpose, etc. (For what it's worth...) --- /home/matt/ftp/nscgi/nscgi-auth.c Mon Aug 11 17:37:58 1997 +++ nscgi-auth.c Tue Sep 28 08:17:07 1999 @@ -187,6 +187,32 @@ NSAPI_PUBLIC int cgiauth_nametrans(pblock *pb, Session *sn, Request *rq) { char *aheader = pblock_findval("authorization", rq->headers); + char *stripdot = pblock_findval("stripdot", pb); + + if (stripdot) + { /* Lets clean up the reference to /. (not Malda!) */ + char *ppath = pblock_findval("ppath", rq->vars); + if (ppath) + { /* Zip to the end of the string and look for . */ + char *c = ppath; + + while (*c) c++; c--; + if (*c == '.' && ((*(c - 1) == '/') || *(c - 1) == '\\')) + { /* I don't know if pblock_findval returns a copy or the + ** original pointer, but let's be safe + */ + pb_param *pp = pblock_find("ppath", rq->vars); + char *oldp; + + c--; /* Strip off the /., not just the . */ + *c = '\0'; + + oldp = pp->value; + pp->value = STRDUP(ppath); + FREE(oldp); + } + } + } if (aheader) { /* There was a header, so see if it matches any of our allow entries.*/ -- Matt Kromer "Where are we going?" "Planet 10!" matt@bane.mi.org "When?" "Real soon!" http://bane.mi.org/~matt
participants (3)
-
Jens Vagelpohl -
Matthew T. Kromer -
Michel Pelletier