some strange output occurs:
Menu for /gdp/html_grass5/html/p.map.html
html
[an internal server error occured]
Obviously these pages are treated as something different
(PHP?).
Any ideas to solve this?
Check the log file(s) of the server for messages.
You might need to turn on debugging information for this.
The HTML code is o.k., I think.
It most certainly is a configuration problem of the webserver
--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Thu, Jan 24, 2002 at 02:09:43PM +0100, Bernhard Reiter wrote:
On Thu, Jan 24, 2002 at 01:11:32PM +0100, Markus Neteler wrote:
> Hi,
>
> while looking at the HTML man pages:
> http://grass.itc.it/gdp/html_grass5/html/p.map.html
> http://grass.itc.it/gdp/html_grass5/html/p.map.new.html
>
> some strange output occurs:
> Menu for /gdp/html_grass5/html/p.map.html
>
> html
> [an internal server error occured]
>
> Obviously these pages are treated as something different
> (PHP?).
>
> Any ideas to solve this?
Check the log file(s) of the server for messages.
You might need to turn on debugging information for this.
> The HTML code is o.k., I think.
It most certainly is a configuration problem of the webserver
Looking into error_log:
[Thu Jan 24 14:07:45 2002] [error] [client 140.XXX] map file
/gdp/html_grass5/html/p.map.new.html, line 2 syntax error: requires at least
two fields
some strange output occurs:
Menu for /gdp/html_grass5/html/p.map.html
html
[an internal server error occured]
Obviously these pages are treated as something different
(PHP?).
Any ideas to solve this? The HTML code is o.k., I think.
It doesn't matter whether or not the HTML code is OK. Even if you give
a ".html" extension to a file of completely random binary data, it
shouldn't cause an internal server error.
My suspicion is that the server has been configured to treat any
filename which contains[1] the string ".map" as a server-side image
map.
It doesn't matter whether or not the HTML code is OK. Even if you give
a ".html" extension to a file of completely random binary data, it
shouldn't cause an internal server error.
My suspicion is that the server has been configured to treat any
filename which contains[1] the string ".map" as a server-side image
map.
[1] as opposed to ending in ".map".
Thanks for the pointer. Looking into the config (not done by me) I
found:
grep map httpd.conf
LoadModule imap_module modules/mod_imap.so
AddModule mod_imap.c
Alias /tmp/ "/tmp/mapserver/"
<Directory "/tmp/mapserver/">
# AddHandler: allows you to map certain file extensions to "handlers",
# If you wish to use server-parsed imagemap files, use
AddHandler imap-file map
So the latter is suspicious. Next question is if I should
switch that handler off as we have the GRASS "mirrors" map: http://grass.itc.it/index.html
On the apache docs I read "This module provides for server-side imagemap
processing."
I assume that this has nothing to do with our map, right?
Switching "AddHandler imap-file map" off should be fine?
It doesn't matter whether or not the HTML code is OK. Even if you give
a ".html" extension to a file of completely random binary data, it
shouldn't cause an internal server error.
My suspicion is that the server has been configured to treat any
filename which contains[1] the string ".map" as a server-side image
map.
[1] as opposed to ending in ".map".
Yes and no.
Yes: the server treats p.map.html as in imagemap (mod_imap).
No: you don't actually have to do anything special to get this
behaviour. I have exactly the same problem here, with a default Apache
1.3.14 setup.
to httpd.conf solves the problem, although it *might* interfere with
other uses of multiple extensions, e.g. as multi-language support (I
don't have anything like this here to test with).
> My suspicion is that the server has been configured to treat any
> filename which contains[1] the string ".map" as a server-side image
> map.
>
> [1] as opposed to ending in ".map".
Thanks for the pointer. Looking into the config (not done by me) I
found:
grep map httpd.conf
LoadModule imap_module modules/mod_imap.so
AddModule mod_imap.c
Alias /tmp/ "/tmp/mapserver/"
<Directory "/tmp/mapserver/">
# AddHandler: allows you to map certain file extensions to "handlers",
# If you wish to use server-parsed imagemap files, use
AddHandler imap-file map
On the apache docs I read "This module provides for server-side imagemap
processing."
I assume that this has nothing to do with our map, right?
Right. That map is client-side.
Switching "AddHandler imap-file map" off should be fine?
Yes. Assuming that you don't have any ".map" files, there isn't much
point in enabling it.
The same applies to any other AddHandler directives, although the only
ones enabled by default are "map" and "shtml", and I doubt that any
filenames will "accidently" contain ".shtml".
On Thu, Jan 24, 2002 at 02:11:23PM +0000, Glynn Clements wrote:
Glynn Clements wrote:
> > while looking at the HTML man pages:
> > http://grass.itc.it/gdp/html_grass5/html/p.map.html
> > http://grass.itc.it/gdp/html_grass5/html/p.map.new.html
> >
> > some strange output occurs:
> > Menu for /gdp/html_grass5/html/p.map.html
> >
> > html
> > [an internal server error occured]
> >
> > Obviously these pages are treated as something different
> > (PHP?).
> >
> > Any ideas to solve this? The HTML code is o.k., I think.
>
> It doesn't matter whether or not the HTML code is OK. Even if you give
> a ".html" extension to a file of completely random binary data, it
> shouldn't cause an internal server error.
>
> My suspicion is that the server has been configured to treat any
> filename which contains[1] the string ".map" as a server-side image
> map.
>
> [1] as opposed to ending in ".map".
Yes and no.
Yes: the server treats p.map.html as in imagemap (mod_imap).
No: you don't actually have to do anything special to get this
behaviour. I have exactly the same problem here, with a default Apache
1.3.14 setup.
to httpd.conf solves the problem, although it *might* interfere with
other uses of multiple extensions, e.g. as multi-language support (I
don't have anything like this here to test with).