get_headers Inconsistency

Question 1

Running the following Code

var_dump(get_headers("http://www.domainnnnnnnnnnnnnnnnnnnnnnnnnnnn.com/CraxyFile.jpg"));

Returns HTTP 200 instead of 404 For any domain or URL that does not exist

Array
(
    [0] => HTTP/1.1 200 OK
    [1] => Server: nginx/1.1.15
    [2] => Date: Mon, 08 Oct 2012 12:29:13 GMT
    [3] => Content-Type: text/html; charset=utf-8
    [4] => Connection: close
    [5] => Set-Cookie: PHPSESSID=3iucojet7bt2peub72rgo0iu21; path=/; HttpOnly
    [6] => Expires: Thu, 19 Nov 1981 08:52:00 GMT
    [7] => Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    [8] => Pragma: no-cache
    [9] => Set-Cookie: bypassStaticCache=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; httponly
    [10] => Set-Cookie: bypassStaticCache=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; httponly
    [11] => Vary: Accept
)

If you Run

var_dump(get_headers("http://www.domain.com/CraxyFile.jpg"));

You get

Array
(
    [0] => HTTP/1.1 404 Not Found
    [1] => Date: Mon, 08 Oct 2012 12:32:18 GMT
    [2] => Content-Type: text/html
    [3] => Content-Length: 8727
    [4] => Connection: close
    [5] => Server: Apache
    [6] => Vary: Accept-Encoding
)

They are so many instances where get_headers has been proven to be a solution to validate existing URL

What is the best way to check if a URL exists in PHP?
How can I check if a URL exists via PHP?

Is This is a Bug or get_headers is not a reliable way for validating URL

See Live Demo

UPDATE 1

Got to find out that CURL also has the same issue

$curl = curl_init();
curl_setopt_array($curl, array(CURLOPT_RETURNTRANSFER => true,CURLOPT_URL => 'idontexist.tld'));
curl_exec($curl);
$info = curl_getinfo($curl);
curl_close($curl);
var_dump($info);

Also returns the same result

Question 2

The problem is nothing to do with the length of the domain name, it is simply whether the domain exists.

You are using a DNS service that resolves non-existent domains to a server that gives you a "friendly" error page, which it returns with a 200 response code. This means it is also not a problem with get_headers() specifically, it is any procedure with an underlying reliance on sensible DNS lookups.

A way to handle this without hardcoding a work around for every environment you work in might look something like this:

// A domain that definitely does not exist. The easiest way to guarantee that
// this continues to work is to use an illegal top-level domain (TLD) suffix
$testDomain = 'idontexist.tld';

// If this resolves to an IP, we know that we are behind a service such as this
// We can simply compare the actual domain we test with the result of this
$badIP = gethostbyname($testDomain);

// Then when you want to get_headers()
$url = 'http://www.domainnnnnnnnnnnnnnnnnnnnnnnnnnnn.com/CraxyFile.jpg';

$host = parse_url($url, PHP_URL_HOST);
if (gethostbyname($host) === $badIP) {
  // The domain does not exist - probably handle this as if it were a 404
} else {
  // do the actual get_headers() stuff here
}

You may want to somehow cache the return value of the first call to gethostbyname(), since you know you are looking up a name that does not exist, and this can often take a few seconds.

Question 3

I assume you're validating POSTed forms: use Zend_Form and Zend_Filter

Question 4

That works in a general case. But not all address line 1's have a number, Some just have a name. eg House Name, Street Name

if your happy with your regex and you just want it to accept a space. Add a space to the regex

$add_check = '/^[a-z0-9- ]+$/i';

But its still not a good way to match addresses. Using a public API which get real data from the royal mail will be the best. Google API (free but rate limited) or a paid for service like Postcode anywhere will be much better for you

Question 5

It's correct, and that's by design.

AFAIK, the function uses the password_hash() php function, and defaults to the PASSWORD_BCRYPT flag, which

PASSWORD_BCRYPT - Use the CRYPT_BLOWFISH algorithm to create the hash. This will produce a standard crypt() compatible hash using the "$2y$" identifier. The result will always be a 60 character string, or FALSE on failure.

That means a salt is automatically generated at each call, and inserted within the generated string, which contains: an identifier for the algo (in this case, $2y$ ), the iteration cost (defaults to 12), the hashed password, and the generated random salt.

That means, thus, everytime you hash your password a new salt is created, therefore the string will always be different - even if the password is the same. That's one of the strengths over a simple md5 hash without salt.

To check it, you use Hash::check(), which uses the password_verify() php function, which analyses the hash, guess the algo used, takes, the embedded salt, and can therefore check if the procedure, given the same starting conditions, creates an identical hash.

Edit

Indeed, this is the method (in Illuminate/Hashing/BcryptHasher)

 * Hash the given value.
 *
 * @param  string  $value
 * @param  array   $options
 * @return string
 */
public function make($value, array $options = array())
{
    $cost = isset($options['rounds']) ? $options['rounds'] : $this->rounds;

    $hash = password_hash($value, PASSWORD_BCRYPT, array('cost' => $cost));

    if ($hash === false)
    {
        throw new RuntimeException("Bcrypt hashing not supported.");
    }

    return $hash;
}

Question 6

After a lot of digging, I found that this has been reported as a bug, fixed in Webkit, but apparently not yet pulled into Google Chrome.

As far as I can tell, the issue was originally reported here: https://bugs.webkit.org/show_bug.cgi?id=35801 :

Description From mitch kramer 2010-03-05 11:37:45 PST

1) create an object literal with one or more properties

2) console.log that object but leave it closed (don't expand it in the console)

3) change one of the properties to a new value

now open that console.log and you'll see it has the new value for some reason, even though it's value was different at the time it was generated.

I should point out that if you open it, it will retain the correct value if that wasn't clear.

Response from a Chromium developer:

Comment #2 From Pavel Feldman 2010-03-09 06:33:36 PST

I don't think we are ever going to fix this one. We can't clone object upon dumping it into the console and we also can't listen to the object properties' changes in order to make it always actual.

We should make sure existing behavior is expected though.

A fix was implemented two and a half years later on August 9th, 2012 for Webkit ( http://trac.webkit.org/changeset/125174 ), but it does not appear to have made it into Chrome yet.

As of today, dumping an object (array) into console will result in objects' properties being read upon console object expansion (i.e. lazily). This means that dumping the same object while mutating it will be hard to debug using the console.

This change starts generating abbreviated previews for objects / arrays at the moment of their logging and passes this information along into the front-end. This only happens when the front-end is already opened, it only works for console.log(), not live console interaction.

get_headers Inconsistency

Is This is a Bug or get_headers is not a reliable way for validating URL

UPDATE 1

Answers

php,validation