Parsing URLs like this: http://www.site.com/month/day/year

molesquirrel

So...this may be a php-solvable problem, or it may be rooted a tag in Apache stuff, but I figured this would be a good place to ask it.

I'm sure you've seen those websites with addresses like:

http://www.weather.com/weather/local/27708

It would be my expectation that '27708' is not a directory, but rather some kind of value. I'd also guess that there may be a /weather/local/index.php or something similiar to it, and somehow it gets the value 27708 sent to it.

With that in mind, does anyone know how to do that? Put more succintly, how does one (if possible) convert

http://www.site.com/value

to ...http://www.site.com/index.php
with index.php being aware of said value, probably in GET or POST form.

Thanks in advance!

swr

The simplest and most portable way is to use PATH_INFO. It is also the most limited.

Suppose you have a PHP script called myscript.php, and you access it like so:
http://www.example.com/myscript.php/foo/bar
If the script does echo $_SERVER['PATH_INFO'] it will echo "/foo/bar". You can use [man]explode/man to turn it into an array.

The thing about PATH_INFO is that it requires a php script be part of the path. Also, PATH_INFO can be turned off in Apache (the AcceptPathInfo setting), and some servers are configured that way.

More flexible is to use Apache's mod_rewrite, which would allow you to invisibly turn a URL like this:
http://www.example.com/foo/bar
into something like this:
http://www.example.com/myscript.php?section=foo&document=bar

Be aware that both of these will have issues if you use relative paths for links or images. If your page here:
http://www.example.com/myscript.php/foo/bar
has an img src="image.jpg" then the browser will try to find it here:
http://www.example.com/myscript.php/foo/image.jpg
because the browser thinks the last slash marks the directory.

dave420

Actually, using REQUEST_URI is the best way. PATH_INFO is a reference to the script file being called, whereas REQUEST_URI is the URI sent to the browser. As you're using a URI for a file that doesn't actually exist, PATH_INFO is not going to work.

Using Apache, you can call a PHP script as a directory:

http://www.server.com/test.php

can be called as:

http://www.server.com/test/

If you add some more data to there:

http://www.server.com/test/some/thing

you can pick this up in your test.php script:

$bits=explode("/", $_SERVER["REQUEST_URI"]);

$bits now contains 3 elements - "test", "some" and "thing".

If you're using Apache and you can get access to either the httpd.conf or .htaccess, using MOD_REWRITE is the best method for this. I use it to redirect requests through a main PHP file, which can sort out which pages the user actually wants (and sort out templates, database access and authentication). The script uses the REQUEST_URI variable to see what was requested, and then work out what it should serve.

swr

Originally posted by dave420
PATH_INFO is a reference to the script file being called

No, it's not. It works exactly as I have described, and has been part of the CGI specification since 1.0.

Some servers turn it off though. In Apache, I believe the option is "AcceptPathInfo".

Using Apache, you can call a PHP script as a directory:
http://www.server.com/test.php
can be called as:
http://www.server.com/test/

I didn't know you could drop the .php extension. Seems to work fine though. Very cool.

If you add some more data to there:
http://www.server.com/test/some/thing
you can pick this up in your test.php script:
$bits=explode("/", $_SERVER["REQUEST_URI"]);
$bits now contains 3 elements - "test", "some" and "thing".

You could do that, but you need to adjust your array indexes depending on how many directories down the script is. PATH_INFO works better in that regard, because it is only the bit after the script name. Try it and see.

Weedpacket

Originally posted by swr
I didn't know you could drop the .php extension. Seems to work fine though. Very cool.

Oh yes, you can have the URL look like anything you want (mod_rewrite works on URLs before the script-handling modules). Quite a few sites I've done make no mention of PHP; all the HTML pages end with ".html", the CSS pages with ".css", and never mind the fact that they're PHP scripts (and that a few of them used to be Perl scripts but you couldn't tell that either because the URLs never changed).

swr

What I thought was cool is that the example dave420 posted (without the .php extension) works independently of mod_rewrite. I just tried it on my test server, shut off mod_rewrite completely and restarted apache, and it still worked. I suppose it is handled by the PHP module instead.

Historically mod_rewrite has been the source of some security issues. Having the option to turn it off and still have a site that works correctly is not a bad thing.

I wonder if it works on IIS as well?

That's one of the benefits of PATH_INFO, it is cross-platform, while mod_rewrite is an Apache thing.