path routing problem with the hosting

[diamond1]

Mc, I did not understand it is the fault of the server settings of the php.ini file? so those using zen cart have this problem of 302 before 404? How to avoid this?

[mc12345678]

Mc, I did not understand it is the fault of the server settings of the php.ini file? so those using zen cart have this problem of 302 before 404? How to avoid this?

So I think you missed the bigger picture, but to be sure. What is it about the 302/404 that you as a visitor that is not indexing or ranking your site but see this response are trying to correct or prevent?

As to the "settings" at the moment all I have is what I found while reviewing the php manual on the header function regarding the special case of say an http/ request.

[kobra]

If it is a server setting in the php.ini file then it is most likely this

; cgi.rfc2616_headers configuration option tells PHP what type of headers to
; use when sending HTTP response code. If it's set 0 PHP sends Status: header that
; is supported by Apache. When this option is set to 1 PHP will send
; RFC2616 compliant header.
; Default is zero.
;cgi.rfc2616_headers = 0

You should determine if your host allows a local php.ini file to adjust settings and if so have them provide you with what is currently loaded with php from there one can adjust settings

[carlwhat]

i find this conversation interesting on a number of levels.

#1 - kobra, i attempted this change on a test server, and it did not solve the problem. i changed the value in my php.ini file, restarted apache and i still got a 302/404 response codes.
#2 - i am NOT convinced that sending a 302 then a 404 is per se a problem. as i have found that:
"The HTTP response status code 302 Found is a common way of performing URL redirection."
#3 - mc, interesting research. i'm not sure i follow it all, but at the end of the day, i can not get my test server to NOT send the 302 response. and it strikes me, no doubt as part of the server setup or something else in some configuration value.
#4 - i looked at a couple of shopify sites as well as a woo-commerce site, and neither one of those sites sends the 302 prior to the 404.

i'm not sure where that leaves us. i have verified and reproduced the behavior, i do not see the same behavior on other carts, & finally i'm not convinced that it is a problem per se.

hmmm.....

[mc12345678]

i find this conversation interesting on a number of levels.

#1 - kobra, i attempted this change on a test server, and it did not solve the problem. i changed the value in my php.ini file, restarted apache and i still got a 302/404 response codes.
#2 - i am NOT convinced that sending a 302 then a 404 is per se a problem. as i have found that:
"The HTTP response status code 302 Found is a common way of performing URL redirection."
#3 - mc, interesting research. i'm not sure i follow it all, but at the end of the day, i can not get my test server to NOT send the 302 response. and it strikes me, no doubt as part of the server setup or something else in some configuration value.
#4 - i looked at a couple of shopify sites as well as a woo-commerce site, and neither one of those sites sends the 302 prior to the 404.

i'm not sure where that leaves us. i have verified and reproduced the behavior, i do not see the same behavior on other carts, & finally i'm not convinced that it is a problem per se.

hmmm.....

In your test to not get the 302, did you force yourself to be viewed as a bot? Ie to not have a session get started?

The 302 as a visitor is somewhat expected after a session has been started because in the initial load process of a page, the sanitizer looks to see about a few settings, but the first time it is encountered (or upon reload of the same page) it sets a session value to true. When the code is then run again for the case of an errant products_id, then with that session value being true a redirect is performed which because it is a generic redirect it issues a 302 based on a standard header redirect as described in the php manual. That redirect takes the "visitor" to the applicable info page (more than likely products_info) where the header file checks for the existence of the products_id and when found not present issues a 404. So... that's in the case of a session being started.

But... bots... which supposedly include search engines... they are not to have a session. Therefore, the sanitizer is expected to never see the session setting that would allow the redirect based on a bad products_id and therefore they get immediately sent to the products_info page and therefore only a 404 is issued without the intermediate redirect/302...

That is if I understood all that is/was going on even though I didn't do a line-by-line review and used what I have come to understand about sessions, bots, and recently the sanitizer. :)

[carlwhat]

ok. again, mc, i appreciate your work. i always learn something when reading your posts. thank you.

i did not force myself to be a bot. i came on as i normally do. and frankly, as i previously documented, the behavior is different in other shopping carts. which makes it more curious here.

let's solve the puzzle. the problem is not with the sessions. the "problem" is in everyone's favorite script:

includes/init_includes/init_sanitize.php

i am not sure why that script validates the products_id and then performs a redirect. validating of the product_id happens in the includes/modules/pages/product_info/header_php.php; and from there the 404 happens. why ZC also does it in the sanitizer, you got me. perhaps, when i have a moment, i will issue a PR to see.

anyways, find this bit of code in the init_sanitize.php (around line 125); comment out the redirect; and the behavior should be straight 404, no 302.

please let me know if it works.

/**
 * validate products_id for search engines and bookmarks, etc.
 */
  if (isset($_GET['products_id']) && isset($_SESSION['check_valid']) &&  $_SESSION['check_valid'] != 'false') {
    $check_valid = zen_products_id_valid($_GET['products_id']);
    if (!$check_valid) {
      $_GET['main_page'] = zen_get_info_page($_GET['products_id']);
      /**
       * do not recheck redirect
       */
      $_SESSION['check_valid'] = 'false';
      // COMMENT OUT THE NEXT LINE!
      //zen_redirect(zen_href_link($_GET['main_page'], 'products_id=' . $_GET['products_id']));
    }
  } else {
    $_SESSION['check_valid'] = 'true';
  } 

best.

[diamond1]

Hello MC thanks for the time that I spend an iced coffee merits, if you tell me what comment I can try if it works