SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    SitePoint Member RogueSkolar's Avatar
    Join Date
    Aug 2012
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Are there downsides to using $_SERVER['SERVER_NAME'] for base URLs?

    Hoping some of you PHP ninjas can shed some light on this.

    I'm currently working between localhost and a remote web server.
    What I'm trying to do if possible is set a server independent base url for
    my image, css, js directories.

    What I have in mind is to set something like:

    $baseURL = $_SERVER['SERVER_NAME'];

    Then I can just reference the aforementioned resources using the variable.

    My thinking is that on localhost, the baseURL variable will return well...
    localhost and on the remote server, it will return something like mysite.com.
    So in a nutshell, I won't need to maintain a set of definitions for localhost and
    another for the remote server.

    My main question is, is this even good practice? I've done a bit of research and
    have come across articles that mention possible security issues but they all fall
    short of outright condemning this practice.

    I'd greatly appreciate your opinion on this.

    Also if you can shed some light on how you'd approach this problem, I'd be much
    obliged, I'm a PHP noob here trying to bring myself up to speed as fast as possible.

    Many thanks.

  2. #2
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,804
    Mentioned
    73 Post(s)
    Tagged
    6 Thread(s)
    @RogueSkolar


    I have used the technique frequently and the only problem encountered was that it fails with subdomains

  3. #3
    SitePoint Addict kduv's Avatar
    Join Date
    May 2012
    Location
    Maui, HI
    Posts
    211
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Yeah, that's really the best way to do it. Some server configurations may not support the SERVER_NAME var, but I'd imagine they are few and far between.

  4. #4
    SitePoint Member RogueSkolar's Avatar
    Join Date
    Aug 2012
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for your insights @John_Betong and @kduv.

    Good to know I need to watch out for "gotchas" on subdomains. I'll look for a
    workaround for this. As it stands, I'm using mainly subdirectories for each of
    my site's categories with only two subdomains, one for an online store and the
    other for a tutorial wiki of sorts.

    @kduv

    The server config at my current webhost seems to support this variable, I'm pretty
    sure it's running PHP 5 and latest Apache with support for 'Nix and windows. I'm
    able to able to customize both php.ini and .htaccess. It's good to know that this is
    something I'll need to look out for if I decide to change hosts in future.

    Big props folks I'm much obliged.

  5. #5
    SitePoint Addict kduv's Avatar
    Join Date
    May 2012
    Location
    Maui, HI
    Posts
    211
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    I would estimate probably 99.9999% of the *nix servers -- I can't speak for the Win servers -- out there support the $_SERVER['SERVER_NAME']; variable. I can't imagine why a sysadmin would disable it. I just wanted to make you aware of the possibility that some server's "may" not support it.

    But really, you're going about it the right way.

  6. #6
    ♪♪ ♪ ♪ ♪ ♪♪ ♪ ♪♪ Markdidj's Avatar
    Join Date
    Sep 2002
    Location
    Bournemouth, South UK
    Posts
    1,551
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I changed my site from using a base url to starting at the root with a forward slash. A lot less characters to send to the client.

    img src="/media/images/example.gif"
    link href="/css/themes/example.css"
    LiveScript: Putting the "Live" Back into JavaScript
    if live output_as_javascript else output_as_html end if

  7. #7
    Utopia, Inc. silver trophy
    ScallioXTX's Avatar
    Join Date
    Aug 2008
    Location
    The Netherlands
    Posts
    9,031
    Mentioned
    152 Post(s)
    Tagged
    2 Thread(s)
    The downside I found with using SERVER_NAME is that on NGiNX, SERVER_NAME contains the main server name, even if an alias is accessed, i.e., I have you have a virtualdomain www.example.com with alias example.com and you access example.com, $_SERVER['SERVER_NAME'] will report www.example.com. Apache handles SERVER_NAME as you would expect though (i.e. reports the accessed host).

    I've found that $_SERVER['HTTP_HOST'] instead of $_SERVER['SERVER_NAME'] works correctly for both Apache and NGiNX.
    Rémon - Hosting Advisor

    Minimal Bookmarks Tree
    My Google Chrome extension: browsing bookmarks made easy

  8. #8
    SitePoint Member RogueSkolar's Avatar
    Join Date
    Aug 2012
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @kduv

    I would estimate probably 99.9999% of the *nix servers -- I can't speak for the Win
    servers -- out there support the $_SERVER['SERVER_NAME']; variable. I can't imagine
    why a sysadmin would disable it.
    Me neither... Still it has been good to know about these gotchas though. Props.

    @Markdidj

    Interesting approach, thanks for your response. Your point about about sending less
    chars to the client is with merit, especially for large documents where the extra code
    that an absolute URL would necessitate could add up. Gotta shave off bytes and kb's
    wherever possible right?.

    I'm a bit confused though about the url that would be generated and the "portability"
    henceforth of each page/article so hoping you can elaborate on your suggestion a bit.
    Unless I've got it totally confused by referencing resources using paths like:

    img src="/media/images/example.gif"
    link href="/css/themes/example.css"

    would this not create URLs that are relative to the doc that references the resource?

    This will work on a "flat" site but on one with subdirectories, where the resources are
    kept in a central place, would this not create broken links? It would mean that I would
    need to change the URL path for each of the docs in the subdirectories so that the links
    are relative to the doc/article/page in question. I could just have this twisted!

    The reason I'm opting for absolute URL paths for resources like images, javascripts,
    stylesheets etc is mainly for maintenance and portability reasons. I am also going
    to implement a data feed of sorts on most pages that will pull article snippets from
    various locations on the site and I'm thinking by using relative paths for images and
    actual links (<a href=""></a> to send visitors to those pages/articles) could
    create broken links.

    I would by all means rather use relative URL paths for stuff like imgs, js etc for ease
    of implementation but since my knowledge of php is near non-existent at this current
    time, I'm not sure how I would go about achieving this easily without some serious
    self education first. If you know of a resource or can point me towards one, I'd be
    grateful. Many thanks.

  9. #9
    SitePoint Member RogueSkolar's Avatar
    Join Date
    Aug 2012
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @ScallioXTX

    Awesome, thanks for the info. This is good to know. My current webhost runs Apache
    so SERVER_NAME seems to be working as expected on the tests I've run. It's good
    to know that if I need to change to a host that runs NGiNX in future, this is something
    I'll need to look out for.

    Props.

  10. #10
    ♪♪ ♪ ♪ ♪ ♪♪ ♪ ♪♪ Markdidj's Avatar
    Join Date
    Sep 2002
    Location
    Bournemouth, South UK
    Posts
    1,551
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    img src="/media/images/example.gif"
    link href="/css/themes/example.css"


    would this not create URLs that are relative to the doc that references the resource?

    No. If you start with a forward slash it references the root directory of the domain you are in, no matter what sub directory you are in.

    It's only when you leave out the first forward slash that it becomes relative
    LiveScript: Putting the "Live" Back into JavaScript
    if live output_as_javascript else output_as_html end if

  11. #11
    SitePoint Member RogueSkolar's Avatar
    Join Date
    Aug 2012
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Markdidj ma man today you have saved me a lot of work!

    So apparently this is a "root-relative" path. I fired up a couple of test pages
    in obscure subdirectories on my remote server and it worked like a charm.
    Gotta love it when things just work!

    I had a couple of issues on localhost though. I've got my sites set up in sub-
    directories with each being defined as a virtual host. The root-relative path
    was resolving to localhost instead of the site's root.

    For example instead of the URL resolving to something like:

    mysite.local.com/assets/img/example.gif

    it was resolving to something like:

    localhost/assets/img/example.gif

    Needless to say the images, css, js etc had broken file paths. I got around this
    by pointing mysite.local.com to 127.0.0.1 in my /etc/hosts file and
    the rest as they say was history.

    Big props guy!

  12. #12
    ♪♪ ♪ ♪ ♪ ♪♪ ♪ ♪♪ Markdidj's Avatar
    Join Date
    Sep 2002
    Location
    Bournemouth, South UK
    Posts
    1,551
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    It was a few years before I realised this as well. I was splitting the URL and concating "../" n times to get to the root.

    It was only when I went to see if it could be improved did I realise it wasn't even needed
    LiveScript: Putting the "Live" Back into JavaScript
    if live output_as_javascript else output_as_html end if


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •