NYCPHP Meetup

[Dan Cech]

edward potter wrote:
> I have not really followed this discussion, but when i see something
> like this:
> "$_SERVER['SCRIPT_NAME'] will contain the full _filesystem_ path,
> which is not what we're after."
> 
> Can you just do a 1 line regex and pull out what you need? And you are
> all set.
> 
> :-) ed

Sure thing ed, care to take a stab at it?  Don't forget that the
filesystem path may actually bear no relation at all to the web path
(aliases and symlinks are enormous fun!) ;)

Dan

> On 12/29/06, Dan Cech <dcech at phpwerx.net> wrote:
>> Michael Sims wrote:
>> > On Tuesday 26 December 2006 5:11 pm, Joseph Crawford wrote:
>> >> Chris,
>> >>
>> >> do you suggest hardcoding the filenames even when referencing the same
>> >> file that is executing?
>> >
>> > There was a long thread about this in July 2005.
>> >
>> > Executive summary: PHP_SELF intentionally includes extra URL garbage
>> (or
>> > valuable URL variables, take your pick) tacked on by the user. 
>> Don't use
>> > it without knowing what it does.
>> >
>> > Here's what you get when you hit the URL:
>> >
>> > http://example.com/info.php/testing1?testing2 :
>> >
>> > _SERVER["REQUEST_URI"]         /info.php/testing1?testing2
>> > _SERVER["PHP_SELF"]    /info.php/testing1
>> > _SERVER["SCRIPT_NAME"]         /info.php
>> >
>> > Get it?  If you don't want that extra stuff tacked on by the user,
>> use the
>> > correct _SERVER variable.  If you use REQUEST_URI or PHP_SELF, be
>> aware the
>> > user can affect the contents of that variable.  99% of the time, you
>> want
>> > SCRIPT_NAME, not PHP_SELF.
>>
>> Actually, I have recently come across a 'fly in the ointment' for this
>> approach.  If you're running php as a cgi, $_SERVER['SCRIPT_NAME'] will
>> contain the full _filesystem_ path, which is not what we're after.
>>
>> I'm not 100% sure what the solution to this problem is.  Right now the
>> only thing I can think of is to try and figure out the common part of
>> PHP_SELF and SCRIPT_NAME, so as to drop both the extra filesystem info
>> and any url garbage, but that seems pretty fragile to me.
>>
>> If anyone has a good solution or even any suggestions I'd love to hear
>> them.
>>
>> Dan