path routing problem with the hosting

[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

[mc12345678]

There still remains the question of what is meant by "it works"...

The sanitizer as I see it at least in this regards, identifies that if the products_id is amiss by someone (not something) navigating the site, then perhaps there is something else that is amiss and therefore it recreates the path that is the next destination in a way that ignores whatever was previously provided. Ie. It sanitizes the content. Afterall, what site would itself display a link to a product that is on the site but isn't an existing product? Little mobius strip there... that's one of the things about maintaining security is identifying where things could be wrong and take an action that is appropriate.

If anything it seems to me that the 302 followed by 404 for someone that is not a recognized search engine or a bot is more of a misunderstood condition than anything. Why is it a goal to remove the 302 I wonder. It's considered a temporary redirect and in this case the result is a 404 page. Okay, so what say you that the last products_id in the store is 180. Now someone tries 181. Nothing there. So should there be a 301 instead? Oops, now products_id 181 is added, but that's a non-existent product from the previous permanent redirection, so what's going on? Is it really a permanent redirect or is it something that should be temporary?

So regarding the line that carlwhat suggested commenting out, if there still was a true need to prevent a valid visitor (session being started) from receiving a 302 and instead some other status code, then I would actually modify that line to have it provide the desired end status code of choice for a product not existing in the catalog. The modification merely would only require adding a comma and the status code just before the last right parenthesis of that line. I still don't see the value in concerning oneself with the response code seen by such a valid visitor/user.

I expect that as a visitor being issued a session that commenting out the above code will prevent the 302 from being issued, but it also removes any sanitization offered by that line moving forward. So I would suggest if you only want a 404 to be issued to anyone/everyone and everything that visits the site using an invalid/unknown products_id then to change the line to:

zen_redirect(zen_href_link($_GET['main_page'], p'products_id=' . $_GET['products_id']), '404');

it will cause two 404s to be issued to those for which it doesn't matter either way, but at least no 302 and no indicator that it is permanently gone.

[mc12345678]

There still remains the question of what is meant by "it works"...

The sanitizer as I see it at least in this regards, identifies that if the products_id is amiss by someone (not something) navigating the site, then perhaps there is something else that is amiss and therefore it recreates the path that is the next destination in a way that ignores whatever was previously provided. Ie. It sanitizes the content. Afterall, what site would itself display a link to a product that is on the site but isn't an existing product? Little mobius strip there... that's one of the things about maintaining security is identifying where things could be wrong and take an action that is appropriate.

If anything it seems to me that the 302 followed by 404 for someone that is not a recognized search engine or a bot is more of a misunderstood condition than anything. Why is it a goal to remove the 302 I wonder. It's considered a temporary redirect and in this case the result is a 404 page. Okay, so what say you that the last products_id in the store is 180. Now someone tries 181. Nothing there. So should there be a 301 instead? Oops, now products_id 181 is added, but that's a non-existent product from the previous permanent redirection, so what's going on? Is it really a permanent redirect or is it something that should be temporary?

So regarding the line that carlwhat suggested commenting out, if there still was a true need to prevent a valid visitor (session being started) from receiving a 302 and instead some other status code, then I would actually modify that line to have it provide the desired end status code of choice for a product not existing in the catalog. The modification merely would only require adding a comma and the status code just before the last right parenthesis of that line. I still don't see the value in concerning oneself with the response code seen by such a valid visitor/user.

I expect that as a visitor being issued a session that commenting out the above code will prevent the 302 from being issued, but it also removes any sanitization offered by that line moving forward. So I would suggest if you only want a 404 to be issued to anyone/everyone and everything that visits the site using an invalid/unknown products_id then to change the line to:

zen_redirect(zen_href_link($_GET['main_page'], p'products_id=' . $_GET['products_id']), '404');

it will cause two 404s to be issued to those for which it doesn't matter either way, but at least no 302 and no indicator that it is permanently gone.

Sorry in trying to edit the text to remove #s I accidentally pressed a letter causing my above recommended code snippet to be wrong. It should have been:

zen_redirect(zen_href_link($_GET['main_page'], 'products_id=' . $_GET['products_id']), '404');

[diamond1]

Hello Mark Thanks I appreciate what you're doing and you're almost there, it works but I get a blank page if the product id does not exist, but if I do a page refresh then you see.

[mc12345678]

Hello Mark Thanks I appreciate what you're doing and you're almost there, it works but I get a blank page if the product id does not exist, but if I do a page refresh then you see.

A blank page should generate an error log in the logs directory. Not sure what action above was taken/tried, but I do know the code I had in one of the previous posts included a letter p next to a quote which would cause an error in such a "test".

[diamond1]

Not by any error in the log folder, do a refresh and the page you see, the strange thing is that if I see the source of the blank page I see that there's a whole page but not displayed.