thank you will do. mike > -----Ursprungliche Nachricht----- > Von: Boyle Owen [mailto:Owen.Boyle@xxxxxxx] > Gesendet: Dienstag, 30. Mai 2006 13:45 > An: users@xxxxxxxxxxxxxxxx > Betreff: RE: [users@httpd] htaccess > > > > -----Original Message----- > > From: Mididoc Productions [mailto:mail@xxxxxxxxxxx] > > Sent: Tuesday, May 30, 2006 1:09 PM > > To: users@xxxxxxxxxxxxxxxx > > Subject: AW: [users@httpd] htaccess > > > > unfortunately the logfiles have been overwritten > > will do a new install. > > You don't have to re-install. A simple restart will recreate the logs if > they don't already exist. The error_log entry is really important > because it will tell you the real filesystem path (ie not just the URL) > of the file that apache cannot find. > > > > > as soon as i get the same php messages i will store them and > > send them to > > you. > > but the questions rests, why the error treatment works with > > all tipped files > > instead php extension. > > You must have (possibly accidentally) configured apache to handle PHP > files somehow. And it's not working... > > > > > if the user tips > > /xxx/inde > > /xxx/index.htm > > etc. > > error 404 is not displayed by the browser > > the redirection gets him to the page we want. > > > > but as soon as he tips > > /xxx/index.php > > or else with .php > > the browser answers with the windows 404 error message > > This is new information - do you mean the "friendly" MSIE error page? If > so, that implies that the server is not sending "enough" data so MSIE > "helpfully" throws it away and creates its own message. Switch this off > (http://www.webwizguide.com/asp/faq/friendly_HTTP_error_messages.asp) > then try again - maybe you're triggering a different error that's not > listed in your ErrorDoc directives... > > Rgds, > Owen Boyle > Disclaimer: Any disclaimer attached to this message may be ignored. > > > and our error treatment getting him to a certain page does > > not work anymore. > > > > thanks for your answers > > > > regards > > > > mike > > > > > > > > > - error_log entry > > > > > > This would be useful... > > > > > > > > - access_log entry > > > > > > so would this... > > > > > > > > - do you actually have PHP installed? > > > > > > > no > > > > > > > > > > > > > - is it configured correctly and working on existing URLs? > > > > > > > > > > Incidentally, I'm a little bemused by this problem of "high > > > > > importance" - it is not usual that users surf a site by > > typing in > > > > > random URLs in the hope that they lead to a page. So I don't > > > > > quite see what all the panic's about. > > > > > > > > It does not matter if I redirect the user to the main-page or > > > > to a special > > > > error page. > > > > Fact is, that the error treatment does not work correctly, > > > > when the tipped > > > > url has the extension php. > > > > > > > > there is no panic around here, especially not here in > > southern france. > > > > it's just making us crazy beeing hacked from people and we > > > > want to defend, > > > > say answer these hacks, > > > > just redirecting them to the main page. > > > > > > Hacks? Requesting a non-existent URL is not a hack, it's a perfectly > > > normal occurance on the web and the protocol defines > > exactly what to do > > > - return a 404 status message. Optionally, the server can > > redirect to > > > another resource, but it's assumed that the other resource > > would give > > > the user *more* information about what went wrong. > > > > > > The routing is not "working correctly" because you have a > > > misconfiguration in your config (did you search it for any > > PHP related > > > directives?). We could probably offer more advise if we > > could see the > > > error_log (it'll say what file it can't actually find) but > > it looks like > > > you can't be bothered to dig that out... > > > > > > Rgds, > > > Owen Boyle > > > > > > --------------------------------------------------------------------- > > 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: users-unsubscribe@xxxxxxxxxxxxxxxx > > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > > > > This message is for the named person's use only. It may contain > confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any > mistransmission. If you receive this message in error, please > notify the sender urgently and then immediately delete the > message and any copies of it from your system. Please also > immediately destroy any hardcopies of the message. You must not, > directly or indirectly, use, disclose, distribute, print, or copy > any part of this message if you are not the intended recipient. > The sender's company reserves the right to monitor all e-mail > communications through their networks. Any views expressed in > this message are those of the individual sender, except where the > message states otherwise and the sender is authorised to state > them to be the views of the sender's company. > > --------------------------------------------------------------------- > 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: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > --------------------------------------------------------------------- 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx