Project

General

Profile

Bug #81720

Updated by Matteo Bonaker over 7 years ago

First off it is important to know what protocol relative urls are. 
 A very brief description is provided by Wikipedia: https://en.wikipedia.org/wiki/URL#prurl 
 In fact all well-known Browsers (except IE 6 and partially IE 7-9) handle PRURLs nicely when used as links. TYPO3 in most cases also does its job when it comes to PRURLs. 
 So now to the actual bug which I found because EXT:dd_googlesitemap does not work with PRURLs due to it. 

 Reproduction: 

 * Install TYPO3 7.6.15 or 8.7.0 (those are the only ones that I tested) 
 * Get in a position to write PHP-Code (e.g. write an extension or modify the core) 
 * Let the url of your site be 'https://example.tld/' 
 * Now in your PHP-Code do @echo GeneralUtility::locationHeaderUrl('//example.tld/path/page.html')@ 
 * Visit your site via 'https://example.tld/' 

 My expected result: 

 > @https://example.tld/path/page.html@ 

 ... because it is the absolute URL that would be generated by the browser for the given input. 

 Actual result: 

 > @http://example.tld//example.tld/path/page.html@ 

 This is the code of the current function @locationHeaderUrl@: 
 <pre> 
         $uI = parse_url($path); 
         // relative to HOST 
         if ($path[0] === '/') { 
             $path = self::getIndpEnv('TYPO3_REQUEST_HOST') . $path; 
         } elseif (!$uI['scheme']) { 
             // No scheme either 
             $path = self::getIndpEnv('TYPO3_REQUEST_DIR') . $path; 
         } 
         return $path; 
 </pre> 

 Even technically the comment above the function contradicts the result. The comment is: 

 <pre>       * Prefixes a URL used with 'header-location' with 'http://...' depending on whether it has it already. 
      * - If already having a scheme, nothing is prepended 
      * - If having REQUEST_URI slash '/', then prefixing 'http://[host]' (relative to host) 
      * - Otherwise prefixed with TYPO3_REQUEST_DIR (relative to current dir / TYPO3_REQUEST_DIR) 
 </pre> 

 And because the double slash at the beginning of a PRURL is not a "REQUEST_URI slash '/'", the result technically would have to be 

 > @/html/typo3///example.tld/path/page.html@ 

 ... which is ridiculous. So the comment is wrong, too imho.

Back