Customizing ProductCart - Using rewrite to remove /store/pc, weird FF issue

Print Page | Close Window

Using rewrite to remove /store/pc, weird FF issue

Printed From: ProductCart E-Commerce Solutions
Category: ProductCart
Forum Name: Customizing ProductCart
Forum Description: Exchange messages with other users that are customizing ProductCart.
URL: https://forum.productcart.com/forum_posts.asp?TID=5815
Printed Date: 27-November-2024 at 9:48am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Using rewrite to remove /store/pc, weird FF issue

Posted By: Brett
Subject: Using rewrite to remove /store/pc, weird FF issue
Date Posted: 03-March-2014 at 6:19pm

We use web.config to rewrite away the /store/pc directory. I don't know if this is related to the issue I'm seeing, but it seems the most likely explanation.

We use the BTO version of PC, and this is the BTO product config page for one of our products:
http://www.liftchair.com/wall-hugger-lift-chair-w-memory-foam-seat-p763.htm

Browsing there directly works fine, as does using the links on our site. However, something strange is happening in firefox that doesn't happen in chrome.

If you refresh the page in chrome, it works as expected. But if you refresh the page (F5 or refresh button) in firefox, it changes the URL to:
http://www.liftchair.com/404.asp?404;http://www.liftchair.com:80/store/pc/wall-hugger-lift-chair-w-memory-foam-seat-p763.htm=

Also, this issue only appears on our BTO Product Config pages, and our regular (non-BTO) products, category pages, and everything else on our site does not have this problem. So, from the looks of it, it's some issue with the combination of "rewriting away the /store/pc directories" and most likely "skip product details (and go straight to the configuration page) for BTO products.

It only happens on firefox - chrome, ie, and safari work fine. The same issue appears on all of our BTO Product Config pages, which is expected as they all use the same code.

Has anyone run into this or something similar before? Any idea how we might troubleshoot it? The page still loads fine, but I'm sure there are issues with the URL being changed like that, at least in terms of duplicate links / content. What's much worse, I imagine it's possible that this is causing google and other search engines to mark our product pages as "404 not found".

*edit*

I'm going to start researching this issue now and will update the thread as I get more information.

Replies:

Posted By: Guests
Date Posted: 05-March-2014 at 1:46am

Hi Brett,

You got my interest on this one. I'm a big fan of rewriting away these directories and have been doing so for years now.

Give me a day or two to circle back on this. I think I know what's up, but no time to test tonight.

Posted By: whizzinpc
Date Posted: 05-March-2014 at 1:20pm

I've seen this on our site. It think it has something to do with the popup for return customer saved cart. Please post a fix if found...

Posted By: ProductCart
Date Posted: 05-March-2014 at 1:45pm

In checking with one of our developers about this... it has to do with the raw error details when Custom 404 Error pages are used. In this case, the server returns the raw error as the query string for Custom Error pages.

http://www.liftchair.com/404.asp?404;http://www.liftchair.com:80/store/pc/wall-hugger-lift-chair-w-memory-foam-seat-p763.htm

In this example, the server redirects customers to the page: "http://www.liftchair.com/404.asp" and the query string is:

404;http://www.liftchair.com:80/store/pc/wall-hugger-lift-chair-w-memory-foam-seat-p763.htm

· 404 - server status code (404: not found)

· ; - separator

· http://www.liftchair.com:80/store/pc/wall-hugger-lift-chair-w-memory-foam-seat-p763.htm -> The URL created the error (80 is HTTP port; 443 or 8443 is HTTPS port)

In most web browsers, the abnormal URL is hidden and replaced with the SEO URL, but not with FireFox (and we cannot control it).

-------------
The ProductCart Team

Home of ProductCart http://www.productcart.com" rel="nofollow - shopping cart software

Posted By: Guests
Date Posted: 05-March-2014 at 10:35pm

Howdy Brett, Art & @earlyimp:

Brett, I popped in for a little testing on a stock BTO location, and confirmed that this behavior has nothing to do with your using URL rewriting to mask the /productcart/pc/ directories. The behavior is the same with or without that URL rewriting in the mix.

I think you've rather nailed it in observing that this only happens on BTO products set to skip the product page and go straight to the configuration page. The explanation by @earlyimp doesn't in any way explain why this behavior on only these pages and not all "SEO URLs" bouncing off of IIS's custom 404 handling, though it explains some of what is going on behind the scenes here:

The ".htm" URL is fictitious, it doesn't exist. IIS detects this as a 404 error, but is set to handle this event by executing /productcart/pc/404.asp. That script parses things out from the query string generated (?404;http://www.liftchair.com:80/store/pc/wall-hugger-lift-chair-w-memory-foam-seat-p763.htm) and having detected from this sting that the page is a product page, it transfers execution to viewprd.asp while returning a 200 status (so, on the client side everything should look just dandy when IIS and this script render the page). Same thing for category and content pages.

What's different on BTO configuration pages set this way is that viewprd.asp detects the "skip details page" setting and transfers again to configureprd.asp. I'm not smart enough to completely get the difference, but clearly the double server.tranfer is what is different, so it's reasonable to assume that's what's causing this behavior in Firefox (or maybe what is revealing "the man behind the curtain" in what is actually happening here) while not on any other pages "bouncing off of" 404.asp.

Given that the behavior is only exhibited on a refresh, I'm not sure whether it's worth getting worked up about from an SEO perspective. However, it would seem that if one really wanted to avoid this, the "skip details" setting could be detected in 404.asp and the server.transfer could be directed immediately to configureprd.asp there rather than first transferring to viewprd.asp and then transfering again to configureprd.asp (as this all happening inside IIS at this point, I'm still puzzling over how Firefox detects this).

As a quick test, I edited 404.asp to transfer directly to configureprd.asp rather than viewprd.asp while hitting a page set this way, and see that there is more to sort out as the product ID got lost that way (though a quick search of why left me wondering why). Anyways, it would take some more investigation/work to handle it that way, but I'm really not sure it would be worth the time/effort unless there's a good SEO reason for it.

Art: I'm curious in what context you've seen this on your site, as I wasn't aware that you were using BTO and it appears to me to only be an issue with BTO products set to skip the details page.

Posted By: whizzinpc
Date Posted: 05-March-2014 at 11:14pm

We only use BTO on some old award items which were removing from the site soon. They are set to skip the details page. We used to have more products using it but all discontinued now. You can search for item 424 on our site to see an example.