init_canonical

[niccol]

Not really sure this is a bug as such but I am not sure that the following code from around ln57 in init_canonical.php is a great idea:

/**
 * SSL Pages get no special treatment, since they don't usually require being indexed uniquely differently from non-SSL pages
 */
  case ($request_type == 'SSL' && substr(HTTP_SERVER, 0, 5) != 'https'):
    $canonicalLink = '';
    break;

By 'special treatment' it actually means 'no treatment',so it produces no canonical links for https pages. And no canonical links at all for sites that run entirely on https.

Hmm ...

(Personally, I'd just treat both http and https equally and make all the canonical urls https - or if one wanted to be clever then use ENABLE_SSL to determine the format for the canonical - in other words if SSL is enabled make all the canonicals https)

[DrByte]

I agree.
I usually comment-out those 3 lines, now that most sites run as https.

[swguy]

If the site is entirely HTTPS, then wouldn't this test fail? So you wouldn't break?
substr(HTTP_SERVER, 0, 5) != 'https'

I can confirm that my all-https site gets canonical links.

[niccol]

Oh....

Yes, partly me being sloppy and forcing the https at apache level. So, I should change the variable in configure.php too.

But actually, I still don't really see the benefit in that code. It is perhaps not the disaster I thought it was (apart from people like me who force https at apache level in which case the canonicals simply aren't there) but it still doesn't seem to do anything of any use. Better perhaps to make the canonicals https for the whole site as long as there is a certificate in place.

[swguy]

Yep, like Dr. Byte said, we should get rid of it - I was just concerned about your analysis of the current behavior.

[mc12345678]

In the "original" use of Zen Cart, the only pages that were really https would be pages such as checkout_xx, login, account_ related. Places where customer's private information would be placed/submitted and more than likely where a SE wouldn't be able to go.

Use of apache to "forward" http requests to https does nothing for the original packet of information intended to be provided by the browser using the certificate. That is why HTTP_SERVER is to be updated to start with https when the site is to go all https. This change is described in the FAQ: https://www.zen-cart.com/content.php...alled-zen-cart
Also by not having HTTP_SERVER set to begin with https where links are not generated to account for $request_type, the link(s) won't be generated using https and then will appear to SEs (and browsers) as mixed or not as all https.
Further (and perhaps this issue was cropping up only in the OPs own site, but) if the software is transferred to another server, not having HTTP_SERVER set to begin with https and possibly not having such apache control means that customers won't arrive at pages using https and result in additional action to finally bring the code in line with the way designed.

The only case where I see that these couple of lines should be removed is where the site actually is all https. It seems to me that there is no quality for Zen Cart to remove this code unless the only options for operating are full https and no https at all.