You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
I have a function for detecting whether or not the home page is the index page or not (to prevent some splash items from not displaying correctly).
The problem is that the function...
<?php function curPageURL() { $pageURL = 'http'; if ($_SERVER['HTTPS'] == 'on') {$pageURL .= 's';} $pageURL .= '://'; if ($_SERVER['SERVER_PORT'] != '80') { $pageURL .= $_SERVER['SERVER_NAME'].':'.$_SERVER['SERVER_PORT'].$_SERVER['REQUEST_URI']; } else { $pageURL .= $_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']; } return $pageURL; } ?>
...is generating the following errors in debug like...
KHXC_Error::error: Non-fatal error encountered: Undefined index: HTTPS File: /skins/LDW/skin.php Line: 10 KHXC_Error::error: Non-fatal error encountered: Undefined index: HTTPS File: /skins/LDW/skin.php Line: 10
...and I don't see why. - I have checked the code (it is correct) and that nothing has been deprecated or the like (it hasn't), so why is generating that error message?
The actual line generating the error is:
if ($_SERVER['HTTPS'] == 'on') {$pageURL .= 's';}
Last edited by Design_Wholesale (02-13-2011 13:52:05)
Offline
As the notes for the $_SERVER superglobal say:
You may or may not find any of the following elements in $_SERVER.
Offline
Yes, but I would be very surprised to find that my server does not support the HTTPS protocol ...so it is not likely that that is the problem, because (also in the documentation) it makes it clear that it is the and not the compiled PHP library that determines what can be returned by that particular superglobal.
Whatever, though, I guess that obviously the codebase is buggy in that area and that, as the function is working, there is nothing I can do about the error save for ignoring it. Thanks for at least confirming that there is nothing critically wrong with the code, though.
Last edited by Design_Wholesale (02-16-2011 13:15:05)
Offline
What leads you to believe something is "buggy"? The fact that a server supports HTTPS has nothing at all to do with whether or not PHP might populate one or more of the $_SERVER superglobal. Any time there is the slightest chance that a variable may not be set you should always test to see if it is set before you attempt to use it.
Offline
Well, fine, but why should the superglobal fail to recognize whether the HTTP server, Apache, supports HTTPS or not? - If it was something obscure that was being checked for I could understand it failing to pick up on it, but being unable to confirm whether the server supports the HTTPS protocol??
Offline