[SOLVED] Internet Explorer BUG [ OC 3.0.2.0 and MSIE ]

OSWorX wrote: ↑

Fri Apr 17, 2020 7:01 pm

ADD Creative wrote: ↑

Fri Apr 17, 2020 6:33 pm

It is a bug in OpenCart. Nothing to do with server-specifics. Any PHP application that uses sessions will need to control what a web browser can cache. That's why if you use the native PHP sessions, PHP will do this for you. OpenCart version 3 onwards implements its own sessions and fails to control what a web browser caches, so web browsers are free to cache any response they want to, leading to problems.

So, to simply break that down to 1 line: do not use OpenCart 3.x if you want to avoid troubles with cache - correct?

OSWorX wrote: ↑

Fri Apr 17, 2020 7:01 pm

So, to simply break that down to 1 line: do not use OpenCart 3.x if you want to avoid troubles with cache - correct?

straightlight wrote: ↑

Fri Apr 17, 2020 8:01 pm

I have contacted Daniel about this. It seem that despite the OC version being used, let's not forget that the pragma-cache deactivation has been suggested since OC v2.x releases on the forum on anyhow which means cache problems have been persistently reported on OC v2.x releases as well. However, the issue seem to be graver than anticipated by design (concept / goals).

straightlight wrote: ↑

Fri Apr 17, 2020 8:01 pm

The problem is that even though we use the gc.session_lifetime suggested by engwalid on Github or disable the pragma-cache, it still won't be a proper solution since for the session lifetime, API services will still be focusing on the shortest session length between services that they use as the same for the store owners by relying on their web service providers.

straightlight wrote: ↑

Fri Apr 17, 2020 8:01 pm

As to disable pragma-cache, it is not a safe solution for online users. It will prevent session validation length to overload the browser, that is correct. However, it won't optimize the stores unless using higher resource capabilities such as better servers which is not how and why Opencart has been intended to be shown as a product.

What we need to get out of this misery, again despite the OC version, is the use of a Cloud-as-a-Service (CaaS) solution. This is a major incident by design ...

ADD Creative wrote: ↑

Sun Apr 19, 2020 1:25 am

Setting cache control headers is the best way to tell web browsers that they shouldn't cache a response.

ADD Creative wrote: ↑

Sun Apr 19, 2020 2:23 am

Any permanent solution to this issue that didn't involve setting cache control headers would be questionable one.

ADD Creative wrote: ↑

Sun Apr 19, 2020 2:33 am

Again, it's not server specific, but client web browser specific.

ADD Creative wrote: ↑

Sun Apr 19, 2020 3:36 am

It's web browser specific in that the OpenCart problem will manifest itself in different ways in different web browsers.

I'll give you a simple example as you clearly don't understand the issue.

1. Goto https://demo.opencart.com/ in Google Chrome. Preferably in a clean session with nothing added to the cart.
2. Open the developer console (F12).
3. Goto the Network tab in the developer console and ensure "Disable cache" is not ticked, "Preserve log" in not ticked and only "Doc" is selected.
4. Click on the iPhone product to go to the product page.
5. Click add to cart. You should see the item add to the the cart at the top of the page.
6. Click the web browser's back button. You will find the cart now shows as empty. This can really confuse some customers.

If you now look in the developer tool Network at tab for demo.opencart.com, in the Size column you can see "(disk cache)". The means that Chrome use the last version from it's cache and did not request the page from the server that would of had the updated cart total.

Try this with version 2.3.0.2 or less and you won't see the issue. You could compare the response headers in the development tool if you like, where you will see the lack of cache control header in version 3.x.

This is just a simple example of the issue. There can be a lot worse problems if the web browser starts caching AJAX responses at checkout, as the original poster to this topic found.

If you have any other questions or need anything explaining in more detail then just ask.

ADD Creative wrote: ↑

Sun Apr 19, 2020 7:18 am

I believed, perhaps wrongly, the information in this topic and the GitHub issue I raised would be plenty of information for any developer to understand. I did not anticipate there would be any need to post in any more detail until it became clearer and clearer that you did not understand it yourself. If you think that is worthy of a official warning then I will just have to accept that.

The actuall example is from viewtopic.php?f=202&t=215712 I just posted easier to understand steps to recreate it. I'll update the GitHub issue with the same steps.

letxobnav wrote: ↑

Sun Apr 19, 2020 9:13 am

Issue is very clear and has been for a long time.

Anything coming out of the response class should not be browser/proxy cached.
Browsers generally cache as much as they can unless explicitely told not to.
V3 Default does not do this.
These headers tell the browsers and proxies exactly that.

I don't care what the difference is between V2 and V3, the development team should know that themselves, I do know that V3 does not set these headers by default and should.

PS.It will also eliminate problems for users how wrongly set expire default and/or expire on text/html in their htaccess because they read on the internet that it would make their site "Fly".

the addressed steps on the above from this post have not been addressed since all this time until today as to know how can the pragma-cache: no-cache can become the only option without providing the steps? !

$response->addHeader('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0'); // prevent browser caching
$response->addHeader('Pragma: no-cache'); // prevent proxy and http/1.0 caching