I wanted to know if it is possible to treat a php file as a directory so that index.php/abc/def really calls index.php. The index.php should then know the subdirectory path (ie /abc/def).
I'm searching a plain php solution. I know that I could use mod_rewrite to map the directory to GET-parameters.
If I recall correctly, you should be able to parse out this info from $_SERVER['PHP_SELF'].
Edit: Even better, take a look at $_SERVER["PATH_INFO"].
This will work if Apache's AcceptPathInfo directive is turned on, which is the default. From the manual:
The treatment of requests with trailing pathname information is determined by the handler responsible for the request. The core handler for normal files defaults to rejecting PATH_INFO requests. Handlers that serve scripts, such as cgi-script and isapi-handler, generally accept PATH_INFO by default.
you can query the path entered using the $_SERVER["PATH_INFO"] directive. You'll have to parse the paths yourself inside the script.
A plain PHP solution is impossible since what is called will be the file.
The PHP in the file does not care where it is or how the file it is in is called other than for include purpose.
What you are looking for is to either convince the OS to pass the /abc/def/ as a parameter to the script or to get the Webserver to do the same thing (ie. mod_rewrite for apache).
Related
Problem: Suppose a URL is requesting a file that doesn't exist, e.g. mydomain.com/index.php/bogus
There is no folder named 'bogus' so I expect a '404 not found' response, but instead Apache sends the request to /index.php (which does exist). Why? How do I change it to respond '404 not found'?
I suppose that, in theory, Apache does this to let me generate a custom index page for the folder 'bogus' (which however does not exist). But in practice, by returning a page with 200 response, it is causing confusion to search engines and accidental visitors. My PHP code in 'index.php' is not expecting this URL and so it generates broken links in its dynamic navigation routines.
I've tried to disable indexes (Option -Indexes) and directory indexing (DirectoryIndex disabled) and removed .htaccess (AllowOverride None). None of these changed the response. I've searched stackoverflow and it has plenty of "how to serve a file instead of 404" but this is the opposite: I want Apache to return 404 instead of serving a PHP file from higher up in the file system.
My server environment is Windows Server 2008, Apache 2.2.22, and PHP 5.3. No mod_rewrite.
The solution that works is to add AcceptPathInfo Off to the Apache config file.
This directive controls whether requests that contain trailing pathname information that follows an actual filename (or non-existent file in an existing directory) will be accepted or rejected. The trailing pathname information can be made available to scripts through the CGI (common gateway interface) specifications.
When AcceptPathInfo is 'Off', the CGI parsing will keep the URL as one long string and look for a file in your filesystem to match.
When AcceptPathInfo is 'On', the CGI will separates the URL into a script name PLUS the following characters are information made available to the script.
The Apache core docs have more info: http://httpd.apache.org/docs/2.0/mod/core.html#acceptpathinfo
You don't have a folder named index.php, you have a file with that name. I think apache finds the file and decides it's found what was requested, so it serves the file.
In your index.php file, you can check that $_SERVER['REQUEST_URI'] is a valid request for index.php. If it isn't a valid request, you can use the PHP http_response_code(404) or header() functions to make your index.php return 404 for invalid URLs.
How do you configure Apache and/or PHP to be able to access PHP scripts without the .php extension? I have seen PHP scripts executed without the .php extension. I don't mean executing 'script' as a PHP file, I mean executing 'domain.com/script' as a PHP file where 'script.php' exists as a file, but you are able to access it without using the extension. Does anybody know how to configure this?
I AM USING A CPANEL HOSTING!
WHERE TO WRITE THE mod_rewrite? I HAVE A .htaccess file with code # Do not remove this line or mod_rewrite rules and search engine friendly URLs will stop working RewriteBase /
Several basic ways:
Use MultiViews. Automatically converts /foo => /foo.php (among other things)
Use mod_rewrite to remove PHP extensions
Use mod_rewrite to direct all traffic to a single dispatcher script, which inspects the URL and performs the proper action by including files / calling class methods, etc.
Generally that's done in Apache via mod_rewrite.
Here's a guide: http://wettone.com/code/clean-urls
Such a rewriting doesn't make too much sense.
If you want (SEO-firiendly|human-readable) URLs, you have to use complete set of rewrite rules, not just removing extension.
Otherwise there would be no point in such a configuration change
I want to create a web site with pure PHP. I want to hide the url parameters. I.e. I want to make my web site with clean urls. Is there is any way to do this with out using any framework? Is cURL helpful to do this?
See URL rewriting in PHP without .htaccess if you don't want to or can't use .htaccess, else refer to How to: URL rewriting in PHP?.
Just have a look on it...before you start your stuffs
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
First of all: It is not possible with PHP only (at least not the forms of URL I think of when reading clean URL). The web server needs to know how to handle requests and what requests are meant to be passed to your PHP script. Otherwise you will probably just get a 404 response.
Because the default behavior of a web server is to just take the requested URL path and try to map it to an existing file below the document root. If a corresponding file was found, either the file’s content is passed back to the client or – as in case of PHP files – the file’s content is passed to an appropriate interpreter and the returned data is passed back to the client. And if the file was not found, well, it responds with the status code 404. So at some point you need to configure your web server.
But after that, when the request was passed to your PHP script, you sure can use just PHP to establish clean URLs. And I would rather suggest to do that with PHP than with web server utilities. Because your PHP application should know best how to handle a requested URL.
In PHP, all required information are in the $_SERVER variable:
$_SERVER['REQUEST_URI'] holds the requested URL path and query (you can parse that with parse_url), and
$_SERVER['PATH_INFO'] holds the PATH_INFO if you’re using that (see Apache’s AcceptPathInfo directive).
Try to rewrite url using php and rewrite url using .HTACCESS.
For example, original url,
www.domain.com/item.php?product=Cars for sale in amazon
with php
www.domain.com/item.php?product=Cars-for-sale-in-amazon
and with .HTACCESS file
www.domain.com/Cars-for-sale-in-amazon
Nope, no curl or framework doing this. Nor php at all.
It is web server who deal with urls.
So, if you want fake urls, you have to set up your web server to redirect certain urls to certain scripts.
The most common way is to use Apache web server with mod_rewrite module
From what I have read and understand of it, there's 2 ways you can do this:
The first being mod_rerite where everything seems to re fone through rewrite rules through the .htaccess file fairly simple to do but can put big load on webserver with large sites
Use PHP to control the rerites this does use .htaccess but only to redirect everything back to the index.php where a dispatcher reroutes paths as necessary. There's a fantastic tutorial of this at phpvideotutorials.com the tutorial is called the tumblelog.
I don't get this:
http://localhost/index.php/articles/edit/1/my-first-article
This URL is mentioned as an example in the Kohana framework documentation. I poked around in the files of my installation, and there is no .htaccess besides my own one that has nothing to do with that.
So, how can it be that an index.php is called but then, as parameters, the stuff looks like added directories to the URL? That doesn't look "real".
Or is this just how native PHP/Apache/HTTP stuff actually works? As I understand it, / is always telling "hey, a directory!". Makes really zero sense to me... how's that possible? Or do they have somewhere an .htaccess that I just can't see / find?
From the Apache docs:
AcceptPathInfo Directive
This directive controls whether
requests that contain trailing
pathname information that follows an
actual filename (or non-existent file
in an existing directory) will be
accepted or rejected. The trailing
pathname information can be made
available to scripts in the PATH_INFO
environment variable.
For example, assume the location
/test/ points to a directory that
contains only the single file
here.html. Then requests for
/test/here.html/more and
/test/nothere.html/more both collect
/more as PATH_INFO.
So I assume this setting is enabled somewhere like in httpd.conf. Note that this, like mod_rewrite, can be enabled/configured in a number of places - see here.
In PHP you can get the data after the filename with the $_SERVER["PATH_INFO"] variable. This allows you to basically GET information without having to use GET variables, which means Google and co will think you're using static pages. This is basically an alternative to mod_rewrite which is often enabled while mod_rewrite is more often not enabled.
This may be obvious to you, but it wasn't immediately to me, this doesn't work correctly on index pages unless you use the filename. For instance, http://example.com/test/my/get/params will not work, while http://example.com/test/index.php/my/get/params will.
AcceptPathInfo is turned on for your server. :)
I'm not using Kohana, so I don't know if my method will be of any use, but when a server doesn't support .htaccess files (or rewrite rules) my 'framework' generates URI's like this:
http://www.domain.com/?/articles/edit/1/my-first-article (notice the ?)
It's a similar method used by the Frog framework, just parse $_SERVER['REQUEST_URI'] (or $_SERVER['HTTP-X-REWRITE-URL'] on windows servers) and explode on the '/'.
This method is completely rewrite independent and still generates more-or-less SEO friendly URI's
Hope it's of any use to you.
Probably not the case here, and certainly not recommended, and probably not the right answer...
BUT ...
I've seen people use 404 pages to parse the request and then include the right page with that information.
See PATH_INFO in CGI Environment Variables.
I'm writting a HTTP server and when i tried the Serendipity PHP Blog i get requests from the browser like this one:
GET /serendipity_admin.php/templates/default/admin/pluginmanager.css HTTP/1.1
The "/serendipity_admin.php" file does exist so the
"/serendipity_admin.php/templates/default/admin/pluginmanager.css" obviously must fail.
What should a webserver do when it discounters such a request?
I tried to just execute "/serendipity_admin.php" with the usual HTTP request headers (REQUEST_URI, PATH_INFO etc), but this does not seem to work so there is some more magick required. Can someone please explain.
the web server will try to match the url from left to right.
since it finds the .php file, it will call it , the rest of the url will then be stored in the $_SERVER['PATH_INFO'] global PHP variable that is available for reading by the script.
Then the script can perform its logic depending on this variable.
REQUEST_URI and PATH_INFO are not HTTP request headers. They are CGI environment variables.
A request for /serendipity_admin.php/templates/default/admin/pluginmanager.css results in /serendipity_admin.php being run with PATH_INFO as /templates/default/admin/pluginmanager.css
You should read the CGI specification.
The blog probably excepts that you are running a module that works like Apache's MultiView. Multiview causes Apache to look for serendipity_admin.php (among other things) if it cannot find the file with the exact path specified in the query.
This looks like it's expecting you to use Apache's rewrite engine. Did it come with a .htaccess file? If so you'll need to set AllowOverride All in the VirtualHost or copy the contents of the file into the virtual host.