php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #66191 relative paths are not handled correctly
Submitted: 2013-11-28 15:22 UTC Modified: 2021-08-11 12:32 UTC
Votes:9
Avg. Score:4.6 ± 0.8
Reproduced:9 of 9 (100.0%)
Same Version:1 (11.1%)
Same OS:4 (44.4%)
From: jakoch at web dot de Assigned: cmb (profile)
Status: Duplicate Package: Built-in web server
PHP Version: 5.4.22 OS: Windows
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jakoch at web dot de
New email:
PHP Version: OS:

 

 [2013-11-28 15:22 UTC] jakoch at web dot de 
Description:
------------
I believe that relative paths are not handled correctly by the embedded server.

I have this in my index.html file:
<link href="assets/css/bootstrap.css" rel="stylesheet">
The file resides in /www/application.

Served by php -S localhost:90 -t c:\www.

When i browse http://localhost:90/application the css is not loaded.
The URL is not resolved to http://localhost:90/application/assets/css/bootstrap.css, but http://localhost:90/assets/css/bootstrap.css. 
Resulting in a resource not found error.

The domain/URI of the current document is not taken into account.

http://www.w3.org/TR/html401/struct/links.html
12.4.1 Resolving relative URIs
3)"By default, the base URI is that of the current document.
The base URI is not the the root of the server.

Screenshot: http://i.imgur.com/1KDW42G.jpg

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-11-28 15:40 UTC] johannes@php.net
-Status: Open +Status: Not a bug
 [2013-11-28 15:40 UTC] johannes@php.net 
These paths have to be resolved b the browser, not PHP as server. Browsers interpret relative URLs relative to the current URL ...
 [2013-11-28 16:13 UTC] jakoch at web dot de 
"Browsers interpret relative URLs relative to the current URL ..."

The current URL is "http://localhost:90/updater" not "http://localhost:90/".
On the screenshot you see, that i get a http code 200 for browsing into the subdir. Then <link href="assets/css/bootstrap.css" rel="stylesheet"> should resolve to http://localhost:90/updater/assets/css/bootstrap.css, but it's requested as http://localhost:90/assets/css/bootstrap.css - logged as "/assets/css/bootstrap.css" - the file is at /updater/assets/css/bootstrap.css.

Putting http://localhost:90/updater in front of the href works, but thats not what i want to use, because the page is served with Nginx. And that works...
 [2013-11-28 16:31 UTC] anon at anon dot anon 
When you browse '/application', the web browser has no way of knowing that 'application' is a directory. It looks like a file in '/'. Consequently, the base URI is '/', so the browser requests resources relative to there. The correct path you should be viewing from is '/application/'. Therefore, it's a web server's responsibility, whenever a directory is requested without a trailing slash, to send a redirect so that it does have a trailing slash. Apparently this vital redirect isn't being sent. I'm not familiar with PHP's built-in web server so I can't say if this missing redirect is a bug in the server or a configuration or user error.
 [2013-11-28 18:07 UTC] jakoch at web dot de 
Demo: https://www.dropbox.com/s/go5ikn4kvryl6e1/php-server-bug.zip

http://localhost:90/application    <-- not working
http://localhost:90/application/   <-- working

Anon, i think you might be right and an implicit redirect would solve this.
 [2014-04-05 00:03 UTC] steve at steveorevo dot com 
I can confirm this. Doesn't happen with Apache or Nginx, but visiting a page without the trailing slash causes subsequent links to fail.
 [2014-09-10 14:11 UTC] magnusthorek at gmail dot com 
I can confirm this too. There is even a post of mine in Stack Overflow (http://stackoverflow.com/questions/25095425/php-built-in-webserver-and-relative-paths) detailing a whole scenario mainly based in relative paths that does not work as expected.

And it's not only with this application I developed. phpMyAdmin also relies on relative paths to load their CSS and JS and the "." is being resolved as one level above, right after the port definition, instead of the current accessed by browser.
 [2014-09-12 15:11 UTC] ibit dot zee at gmail dot com 
I can confirm this problem is real for relative links...

Same app tested with several other Server IIS5/IIS6/IIS7 and Apache works ok...

PHP internal server is trying to find the resource indicated by the relative path always in the parent folder...

try also with './*' prefix, no prefix, only works with absolute path... and this is very annoying... please fix (php 5.3x)
 [2016-05-20 09:16 UTC] bobvantoorn at gmail dot com 
I'd hate to say '+1', but this bug is still set to status 'not a bug'. I am experiencing the same problem with PHP 5.6.

Please take another look at the ticket description and at useful comments that were added since it was marked as 'not a bug'.

Thanks!
 [2017-02-09 05:19 UTC] nerax3s at gmail dot com 
This is definitely a bug but still marked as "Not a bug" and not fixed as of PHP 5.6.30 .
 [2017-02-09 11:53 UTC] johannes@php.net
-Status: Not a bug +Status: Open
 [2017-02-09 11:53 UTC] johannes@php.net 
As said the relative handling comes from the client. But there is indeed a bug:

On a "GET application" the server has to do a redirect (304?) to "application/" in case this is a directory.
 [2021-08-11 12:32 UTC] cmb@php.net
-Status: Open +Status: Duplicate -Assigned To: +Assigned To: cmb
 [2021-08-11 12:32 UTC] cmb@php.net 
Right, the redirect is not triggered, what has been requested as
request #67027.  I'm closing this ticket as duplicate.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Nov 22 00:01:30 2024 UTC