On Tue, Aug 02, 2005 at 11:15:24AM +0100, Brian Candler wrote:
> Cheers. I've moved over to the mirfak mod_frontpage, but still get the same
> error now:
Right, well this is turning into a long voyage of discovery :-)
Firstly, I was able to get mod_frontpage working with a vanilla httpd and
install_fp.sh (all done inside a chroot environment).
Then I tried to get rid of the <VirtualHost> + DocumentRoot in the Apache
config, replacing it with:
-----------------------------------------------------------
RewriteEngine On
RewriteMap tolower int:tolower
RewriteCond ${tolower:%{HTTP_HOST}} =www.example.com
RewriteRule ^(/_vti_bin/?.*)$ /usr/local/www/data-example$1
[T=application/x-httpd-frontpage,L]
RewriteCond ${tolower:%{HTTP_HOST}} =www.example.com
RewriteRule ^(.*)$ /usr/local/www/data-example$1 [L]
-----------------------------------------------------------
(BTW these are pasted verbatim; I mapped www.example.com using the 'hosts'
file on the test Windows client). At this point, frontpage gave an error but
it was hidden because it seems Microsoft are unaware that CGIs need to
generate headers.
[Tue Aug 2 13:21:24 2005] [error] [client x.x.x.x] malformed header from
script. Bad header=<html><head><title>vermeer RPC: /usr/local/sbin/fpexec
Just a 500 error came back to the client. So, I patched fpexec.c to fork a
child process, and add "Content-Type: text/html\r\n\r\n" if the CGI output
starts "<html>". This revealed the true error: Cannot open "frontpg.lck": no
such file or folder
0x0130: 3c68 746d 6c3e 3c68 6561 643e 3c74 6974 <html><head><tit
0x0140: 6c65 3e76 6572 6d65 6572 2052 5043 2070 le>vermeer.RPC.p
0x0150: 6163 6b65 743c 2f74 6974 6c65 3e3c 2f68 acket</title></h
0x0160: 6561 643e 0a3c 626f 6479 3e0a 3c70 3e6d ead>.<body>.<p>m
0x0170: 6574 686f 643d 6c69 7374 2064 6f63 756d ethod=list.docum
0x0180: 656e 7473 3a35 2e30 2e32 2e32 3633 340a ents:5.0.2.2634.
0x0190: 3c70 3e73 7461 7475 733d 0a3c 756c 3e0a <p>status=.<ul>.
0x01a0: 3c6c 693e 7374 6174 7573 3d31 3331 3039 <li>status=13109
0x01b0: 330a 3c6c 693e 6f73 7374 6174 7573 3d35 3.<li>osstatus=5
0x01c0: 3336 3837 3039 3134 0a3c 6c69 3e6d 7367 36870914.<li>msg
0x01d0: 3d43 616e 6e6f 7420 6f70 656e 2026 2333 =Cannot.open.
0x01e0: 343b 6672 6f6e 7470 672e 6c63 6b26 2333 4;frontpg.lck
0x01f0: 343b 3a20 6e6f 2073 7563 6820 6669 6c65 4;:.no.such.file
0x0200: 206f 7220 666f 6c64 6572 2e0a 3c6c 693e .or.folder..<li>
0x0210: 6f73 6d73 673d 4e6f 2073 7563 6820 6669 osmsg=No.such.fi
0x0220: 6c65 206f 7220 6469 7265 6374 6f72 790a le.or.directory.
0x0230: 3c2f 756c 3e0a 3c2f 626f 6479 3e0a 3c2f </ul>.</body>.</
0x0240: 6874 6d6c 3e0a 0d0a html>...
frontpg.lck exists, but it's under _vti_pvt. Since it worked before, this
implies that either the cwd or the environment is different when frontpage
is running in this mod_rewrite way.
So another patch to show the cwd and environment, and the only significant
differences are:
-DOCUMENT_ROOT=/usr/local/www/data-example
+DOCUMENT_ROOT=/usr/local/www/data
-SERVER_NAME=www.example.com
+SERVER_NAME=bloodhound.real.domain
plus SCRIPT_URL and SCRIPT_URI were set in the mod_rewrite case, but not the
virtualhost case.
So I thought the script depended on these values being correct. Using
[E=DOCUMENT_ROOT:...] is not sufficient to override it, so another patch to
fpexec.c was required to update the environment. Unfortunately, that did not
fix it :-( I also checked argv[] is the same in both cases.
An inspection of mod_frontpage.c didn't help me.
But then I hit on something: I tried setting DocumentRoot statically in
httpd.conf to point to /usr/local/www/data-example, and *that* made it work.
So for some reason, DocumentRoot within Apache must be set correctly for
mod_frontpage to work.
Unfortunately, it doesn't seem to be possible to set DocumentRoot with
mod_rewrite. The Apache docs say at
http://httpd.apache.org/docs/1.3/vhosts/mass.html
| "The other thing to `fake' is the document root (configured with
| DocumentRoot and available to CGIs via the DOCUMENT_ROOT environment
| variable). In a normal configuration this setting is used by the core
| module when mapping URIs to filenames, but when the server is configured
| to do dynamic virtual hosting that job is taken over by another module
| (either mod_vhost_alias or mod_rewrite) which has a different way of doing
| the mapping. Neither of these modules is responsible for setting the
| DOCUMENT_ROOT environment variable so if any CGIs or SSI documents make
| use of it they will get a misleading value."
I did also wonder if mod_frontpage is intercepting the /_vti_bin/ call
before mod_rewrite is. However, I have mod_frontpage at the top of my module
list:
ClearModuleList
AddModule mod_frontpage.c
AddModule mod_mmap_static.c
...
IIUC, this means that it should be tried *after* mod_rewrite, which comes
later.
At the moment, I'm thinking that I'll have to write a virtual hosting module
which will lookup the Host: header in a .db/.cdb file and set DocumentRoot
dynamically. It'll be a shame if I have to go to this trouble :-(
Anybody know of such a module? I definitely want a local .db/.cdb file, not
a MySQL or LDAP lookup.
Regards,
Brian.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
