403 Error For PHP Pages

MarkP wrote:
> had another quick look over the info output, and sure enough, it looked
> like it was trying to save session stuff to c:\php\sessiondata so I
> created the folder, and that's got rid of all those nasty error
> messages.
>
this is the line in the php file
session.save_path = "c:\php\sessiondata"

you might want to consider moving it away somewhere else though,
because these files should be protected from path prediction attacks.

>
> Just need to get the MOD_REWRITE bit working, and I can go to sleep
> tonight a happy man. :o)
>
> Now, my mod_rewrites are not working at all, I don't get any errors,
> other than a lovely ie page with page cannot be found. I have a
> .htaccess file where ( I think ) it should be, but how do I go about
> debugging this bit ??

if you want to use htaccess thats fine. but they are off by default for
performance reasons, its a good idea to keep them off unless you need
to replicate some non-root server.

in httdp.conf you can simply define the rewriterule within a directory
block, hers one that redirects all attempts to the index.php file if
the client requests a file or directory which doesnt exsit

<Directory "C:/path/to/your/domains/web/root">
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L,NS]
</Directory>

notice the forward slashes (rahter than backwards ones which windows
users are used to)

you can put this inside an .htaccess file (notice the dot) in the web
root, but you will have to locate the directive in the httpd.conf which
says
AllowOverride none
and change the word none to all

apache will now check every directory up to an including the final one
in the request for .htaccess files which sows it down somewhat when
each page has 20 elements in it.

The above rewrite uses rewritecond statements to limit when it is used,
if you want to fine tune your rewrites just turn on rewrite logging

#ReWriteEngine On
#ReWriteLogLevel 9
#ReWriteLog "logs/rewrites"

somewhere outside the directory block.

notice the relative path to logs, so it will appear in the logs
directory above server root. If you have defined the server root inside
the httpd.conf.


good luck.
and just a /quick/ note about paths. You see php as the apache module
looks first in the apache bin folder, and then in the php folder, THEN
in %systemroot%, sooo where php.ini is can make a difference as to
where the directives point, because they are defined /relatively/ to
where php.ini is located! Hence my original suggestion to move it to
where it would result in stndard paths, ie php/ext, php/sessiondata
etc... However, of course you can solve this problem by hard coding
stuff, or even environmental variables. I wont argue with what you are
comfortable doing!!
for instance when I got my php.ini first, it had this for sessions
session.save_path = "tmp"
not at all what i wanted, so I hard coded it using an absolute path to
point somewhere away from the standard folder.

Beers all round boys !!!!

It was indeed the AllowOveride All line that did the trick. I have a
couple of bits to update with regards to the database, as it's
currently not an exact copy of my web database, but that's easily
sortable.

All I now need is a masterclass in more complex rewrite rules - any
takers ??

But seriously, thanks so much for all your help, I can sleep happy
tonight !!!

Mark.

One final things guys that someone has just thrown at me - which is
better to do :

a). rewrites with mod-rewrite
b). 404 redirects using php

What are your thoughts ?? do you currently use either or both ?? are
there any downsides other than performance with mod-rewrite ??

Mark.

MarkP wrote:
> One final things guys that someone has just thrown at me - which is
> better to do :
>
> a). rewrites with mod-rewrite
> b). 404 redirects using php
>
> What are your thoughts ?? do you currently use either or both ?? are
> there any downsides other than performance with mod-rewrite ??
>
> Mark.

with MVC you use rewrites to shove all requests into a controller that
collects what the original request was for and uses application logic
to deliver the rest. It is a very clean and nice way to make a complex
website.
Rewrites combined with php is almost mandatory for an advanced site.
Login redirection of specific status code, etc... is usually governed
by standards in your application, but url convenience and human
readableness usually required rewrites+controller.

"MarkP" <mark_paceyuk@yahoo.co.uk> schreef in bericht
news:1165270882.221453.93750@16g2000cwy.googlegrou ps.com...
> One final things guys that someone has just thrown at me - which is
> better to do :
> a). rewrites with mod-rewrite
Mod_rewrite main task is to change -aka rewrite- the *mapping* of an URL to
a local file.
It can be used to do redirect or forwarding to a proxy of a [modified]
request too.
It can even test and set a cookie; if you like it'll redirect only if a
given cookie is missing

Currently it is quite often used to remap a 'google freindly 'url like
/images/flowers/cymbidium.jpg
/document/text.html
to
/cgi-bin/logo.xyz?pic=flowers/cymbidium.jpg
/cgi-bin/pagemaker.cgi?doc=text.html

> b). 404 redirects using php
Shiver ... 404 document not found ... is not a redirect like 301 Moved
Permanently and 302 Found

A program or script -in any language- is in theory able to retrieve data
from any source. If data is retrieved from a local filesystem infact the
mapping of the url to a file is modified, that 's the basic task of
mod_rewrite ....

A program or script may choose to respond 302 and redirect to a login-script
when a (session)cookie is missing. Do-able by rewrite too ...

> What are your thoughts ??
> do you currently use either or both ??
Both

> are there any downsides other than performance with mod-rewrite ??
Before the use of mod_<language> forking a process to run the script
CGI-wise for each and every request caused a bigger hit on performance, in
those days mod_rewrite was the lesser bad option.

The use of rewrites tends to be less obvious and transparant to the
*content* maintainer of a site.
This can be mittigated when used in .htaccess 'right next to the documents
involved'
However, [allowing] the use of .htaccess -with or without rewriterule- and
in particular at the document root, has a negative impact on performance: a
path is traversed folder by folder for each request and each .htacces found,
is freshly *interpreted*.

Many hosting companies do not allow the use of rewrites or even .htaccess, a
script is your only chance to do things yourway.


HansH