SPA (Single-page app) load always from cache - caching

I have a SPA (Single-Page Application) written using OpenUI5 framework.
It works well (when I'm in debug mode or using cache-killer https://chrome.google.com/webstore/detail/cache-killer/jpfbieopdmepaolggioebjmedmclkbap) but now I have pushed the app on the server apache: here the problems started...
Users not have cache-killer installed and I would like update the app on the server and immediately have the new version of the app on the users pcs at the successive refresh.
In my app I have a series of tab: each tab have a content and I have two different content for each tab (a display fragment content and a change fragment content).
When I load the page, by default, tabs are filled by display fragments; then I press a button and the content of each tab swithc to the change fragments.
The problem is that all fragment that I retrieve after the first page loading are loaded (from cache)...
I try to use manifest application cache and the various meta-tags (see Chaching with single-page application) but the problem not change and it is still there.
This is a request-response header for the diplay fragment (correcly loaded from the server)
General:
Request URL:http://10.7.1.96/www/temp_ftp_grunt/view/tab/article/TabAnagrDisplay.fragment.xml
Request Method:GET
Status Code:304 Not Modified
Response header:
HTTP/1.1 304 Not Modified
Date: Thu, 17 Sep 2015 14:45:43 GMT
Server: Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.5.6
Connection: Keep-Alive
Keep-Alive: timeout=5, max=46
ETag: "38b6-51ff07d7bfe81"
Request Header:
GET /www/temp_ftp_grunt/view/tab/article/TabAnagrDisplay.fragment.xml HTTP/1.1
Host: 10.7.1.96
Connection: keep-alive
Cache-Control: max-age=0
Accept: application/xml, text/xml, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
Referer: http://10.7.1.96/www/temp_ftp_grunt/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: it,en-US;q=0.8,en;q=0.6
If-None-Match: "38b6-51ff07d7bfe81"
If-Modified-Since: Thu, 17 Sep 2015 12:24:01 GMT
and this for the change fragment loaded from cache
General:
Request URL:http://10.7.1.96/www/temp_ftp_grunt/view/tab/article/TabAnagrChange.fragment.xml
Request Method:GET
Status Code:200 OK (from cache)
Response header:
Accept-Ranges:bytes
Content-Length:23642
Content-Type:application/xml
Date:Thu, 17 Sep 2015 14:44:47 GMT
ETag:"5c5a-51ff1965857b1"
Last-Modified:Thu, 17 Sep 2015 13:42:33 GMT
Server:Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.5.6"
Request Header:
Provisional headers are shown
Accept:application/xml, text/xml, */*; q=0.01
Referer:http://10.7.1.96/www/temp_ftp_grunt/
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
X-Requested-With:XMLHttpRequest
For OpenUI5 developers: I have loaded the fragment in this moode:
1.display fragments in onInit function of the controller that contain the list of tabs
var oTab = new sap.m.IconTabFilter();
oTab.addContent(myfragment);
tabBar.addItem(oTab);
2.change fragments by a function that remove the display frg by tabBar.removeAllItems(); and add the new frg in the same mode of 1.
I have tried to find a solution to my problem; I have read this https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching and this http://alistapart.com/article/application-cache-is-a-douchebag articles but I can't find the solution for my problem. Cache buster https://openui5.hana.ondemand.com/#docs/guide/91f080966f4d1014b6dd926db0e91070.html suggested here Force clear cache in OpenUI5 require a SAP backend

We had the same problem and managed by defining a new path for fragments
sap.ui.localResources("fragments");
By default, fragments was in the same folder than Libraries (resources) and always caching.

Related

Status 200 (from disk cache) and 304 Not Modified issue

I'm using Next.js custom server, which by default sends strong ETag header on each page GET request. For each request I also manually add Cache-Control header res.setHeader('Cache-Control', 'public, max-age=${60 * 60}, s-maxage=${60 * 60 * 24}, must-revalidate')
Also I'm using Cloudflare's loadbalancing and caching mechanism. According to this documentation https://support.cloudflare.com/hc/en-us/articles/218505467-Using-ETag-Headers-with-Cloudflare I sutisfied each requirement related to strong ETag. And the page rule was configured as following:
page rule configuration screenshot.
First strange behaviour is that on a client in headers I noticed for some reason weak ETag. Also the behaviour of caching is little strange. If I'll open a new site post, I'll be usually faced with cf-cache-status: HIT header, which means that Cloudflare already have prepared cache for this specific post. My expectation is that after page reloading in same tab, the page will be recreated form disk cache, but for some reason it makes a request, result of which is status 304 (Not Modified). BUT, if I'll copy the url and open the same post in new tab, it will be recreated from disk cache (as it should), and also after page reloading it makes request with response 304 (Not Modified).
Direct origin server request-response:
General:
Request URL: ...
Request Method: GET
Status Code: 200 OK
Remote Address: ...
Referrer Policy: strict-origin-when-cross-origin
Response headers:
cache-control: public, max-age=3600, s-maxage=86400, must-revalidate
connection: keep-alive
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Thu, 28 Jan 2021 13:02:42 GMT
etag: "62e33-f1yLCVYVUzVH67UMp/2WOxQqfC8"
transfer-encoding: chunked
vary: Accept-Encoding
x-powered-by: Next.js
Request headers:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
Cache-Control: no-cache
Connection: keep-alive
Cookie: _ga=GA1.1.1009400285.1608315387; _gid=GA1.1.1795438935.1611755271; _gat=1
Host: ip_here
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Cloudflare proxy request-response:
General:
Request URL: ...
Request Method: GET
Status Code: 200
Remote Address: ...
Referrer Policy: strict-origin-when-cross-origin
Response headers:
age: 44448
cache-control: public, max-age=3600, s-maxage=86400, must-revalidate
cf-cache-status: HIT
cf-ray: 618ac665c984351f-KBP
cf-request-id: 07ea9a539d0000351f0faf7000000001
content-encoding: br
content-type: text/html; charset=utf-8
date: Thu, 28 Jan 2021 12:39:13 GMT
etag: W/"62e33-vLyavPBB7axQJnhj/OKdPyUNp+A"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
nel: {"max_age":604800,"report_to":"cf-nel"}
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=4ASHxxkyb8necnQhGaz8th4W%2FcFEwzrBwYiidFGsHK5ZZJ%2BGEYWbmOlDSC2Uep2TYw8vYUm0DL4WkrdC9xsIK%2F6j0G1QF%2BK5817fQQ%3D%3D"}],"max_age":604800,"group":"cf-nel"}
server: cloudflare
vary: Accept-Encoding
x-powered-by: Next.js
Request headers:
:authority: ...
:method: GET
:path: ...
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
cache-control: max-age=0
cookie: _ga=GA1.2.33365049.1592837735; __cfduid=d58947d60ae6adfce59e944d190e702ae1610627770; _gid=GA1.2.788163791.1611406644; connect.sid=s%3AfLFtBQSejs6Jf0gkdqiRhyzAnu8ImE_J.KukkQj15FMXkfcW6alO6BPUYT8SgPWRqtu2xo2QRe8U; __cflb=0H28urhoa5eNWhDb7XVCL24Hq5fwW5bc37oc693mgWx; _gat=1
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: same-origin
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Why is it happening? In ideal I want to recreate page from disk cache in nearest hour and after it make a revalidation request. And make Cloudflare's cache revalidation each day from origin server.
You can see in headers that ETag is different between origin server and cloudflare

Prestashop module stuck in maintanance mode

I have got weird problem with my prestashop's module. I use JS script, which takes possible colors depending on the product's category and choosen language, from my module and suggest them as possible values in customization form field. When works it should look like this:
Data is beeing obtained from shop's module in myurl.com/en/module/mymodule/getcolors?prod=37 where prod is product's ID. Based on product's ID module checks which category it is and which set of colors is available and returns them as JSON response.
It worked some time, but then needed to do some changes and now on some devices it does not work anymore. It works on my home computer and in work, but it does not on my smartphone and my paretns laptop.
What happens when i enter myurl.com/en/module/mymodule/getcolors?prod=37 url?
On devices where module works i see JSON response with available colors, but on devices where module does not work i see info about prestashop's maintanace mode as the shop was offline!
I tried to:
turn on/off maintanance mode couple of times (with debug mode on and off),
manually delete smarty cache files,
manually set PS_ENABLE_SHOP to 1 in database config table
I had same problem when i started to use this module, but somehow it started to work. Any ideas what to do? It seems like some kind of problem with cache.
Edit:
https://myurl.com/en/module/mymodule/getcolors?prod=37
Host: myurl.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: pl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: _ga=GA1.2.1785140579.1576511420; PrestaShop-802a277372a8bab414734d0de4ba8899=def502007f9698a628f473fe5e0361b2d2ae59ea7be7280fc40ffe5d1f18095a7a9d4da956eb114678b6ff2375a7540d17f868820d39db6c4c3d67b105e9cd0ff648e45609c3f119afddb50db22b06f43ce6aa973447dca317420bf7578ae606cb7737eece27c6b935b0a68c91755218abfc300819b3698d95239d8f99791526596e9285fcbc499a4bc41d7521c6f96b1074bd4213d768d19c2ba663f22babb4277fd642881156fdfcc5f552cb48d4a30aac54d4174b4d9a153e17b7cb21c3e4a16ce808cadbf466262a949b1b5228e1d35882635f8b45bb3d8f439f; _gid=GA1.2.30008684.1579769668; PHPSESSID=subde22b0oe571kq0o0s336r27
Upgrade-Insecure-Requests: 1
GET: HTTP/1.1 500 Internal Server Error
Date: Fri, 24 Jan 2020 10:08:59 GMT
Server: Apache/2
X-Powered-By: PHP/7.0.33
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Vary: Accept-Encoding,User-Agent
Connection: close
Content-Type: text/html; charset=utf-8
X-Content-Encoding-Over-Network: gzip
Transfer-Encoding: chunked
This is the HTTPheaders on computers which seems to work. But as you can see the status of response is 500. On computers where i get maintanance mode info response's status is 307. What can be wrong?

Cloudflare Edge cache TTL

I've been testing Cloudflare, and I have Edge TTL set for 1 month for everything in the images folder. I'd like to see if this is set correctly, but in the Response Headers I don't see an EDGE TTL expiry. Is there any way for me to see when the cache will expire for an object in Cloudflare?
Here's the sample headers:
Response Headers
Request URL:https://cdn.mysite.com/content/testimage.jpg
Request Method:GET
Status Code:200
Remote Address:104.27.138.237:443
Referrer Policy:no-referrer-when-downgrade
Response Headers
accept-ranges:bytes
cache-control:public, max-age=14400
cf-cache-status:HIT
cf-ray:37fa88117ff010f3-ORD
content-length:10512
content-type:image/jpeg
date:Mon, 17 Jul 2017 04:41:54 GMT
etag:"b9a9dca80fa816483b4df7e970639c98"
expires:Mon, 17 Jul 2017 08:41:54 GMT
last-modified:Mon, 17 Jul 2017 04:13:53 GMT
server:cloudflare-nginx
status:200
vary:Accept-Encoding
via:1.1 d784ab98a21beb476de2ec8d5824cf82.cloudfront.net (CloudFront)
x-amz-cf-id:MhQHg0-wZ_l7yEPeFkOvt7JXn4xuicRBpIVw2jlcy6Lt9KvukCrFcw==
x-amz-meta-s3cmd-attrs:atime:1499536352/ctime:1499536352/gid:1000/gname:sluser/mode:33204/mtime:1499536352/uid:1000/uname:sluser
x-cache:Miss from cloudfront
Request Headers
:authority:cdn.mysite.com
:method:GET
:path:/content/testimage.jpg
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8
cache-control:no-cache
cookie:__cfduid=df4ff5a2242e05fbc12499e832333f59c1500222401
pragma:no-cache
upgrade-insecure-requests:1
user-agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Because EDGE TTL expiry are not reflected in the response header. They use this for their internal parameter to store files.
Visit this link for more detail
https://support.cloudflare.com/hc/en-us/articles/200168376-What-does-edge-cache-expire-TTL-mean-

Google app engine Endpoint and HTTP Sessions

I'm deploying an application in Google App Engine and I'm also using the Cloud Endpoint feature for REst call.
I use a custom domain to point on my application. As you probably know, Endpoint doesn't support custom domain. So my situation is this:
I open the page http://www.example.org
I do an ajax request to an Endpoint like https://my-example.appspot.com/_ah/api/service
Now the problem is: Everytime I do an ajax request to an Endpoint, a new Session is created!! How can I keep the session between requests? I inspected the responses from Endpoint, and I didn't find any reference to session cookie...
UPDATE 1
For the Ajax call I'm using JQuery.
$.post('_ah/api/user/v1/login', function() {
console.log('logged');
});
I now add this is for adding the withCredentials field.
$(document).ajaxSend(function(elm, xhr, s) {
xhr.withCredentials = true;
});
UPDATE 2
This is my request and the server response headers
Request
Accept:*/*
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Origin:http://www.example.org
Referer:http://www.example.org/game.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
X-CSRFToken:xkNZPouvfl2mRT0IKFZNB2xJpffaaK3UuYhhg5eoeRAiMqxaoQ14q93cv2xeRnYP
Response
access-control-allow-credentials:true
access-control-allow-origin:http://www.example.org
access-control-expose-headers:Content-Encoding,Content-Length,Content-Type,Date,Server
alternate-protocol:443:quic,p=1
cache-control:private, max-age=0
content-encoding:gzip
content-length:165
content-type:application/json; charset=UTF-8
date:Sun, 19 Apr 2015 12:40:49 GMT
expires:Sun, 19 Apr 2015 12:40:49 GMT
server:GSE
status:200
version:HTTP/1.1
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block

CORS does not work

I need to write an ajax request, which will request an XML from REST service. I deployed locally a simple REST service, which returns an XML document.
I know about same origin policy, so I added Access-control-allow-origin: * to the response (or the same value like in Origin header in request). Then I tested my ajax request from a local html file and got same origin policy error.
I then tried to put this page into java web application, deployed it into tomcat and got the very same error. I've tested it in Chrome and Firefox.
It only works if I start Chrome with disabled web security. But it does not solve my problem.
That's the request, sending by ajax, which receives
**OPTIONS http://localhost:9198/helloworld Origin http://localhost:8081 is not allowed by Access-Control-Allow-Origin.**
For both cases. Whether it is an * in the Access-control-allow-origin or defined host.
Request URL:http://localhost:9198/helloworld
Request Method:OPTIONS
Status Code:200 OK
Request Headers:
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Access-Control-Request-Headers:accept, customheader, origin
Access-Control-Request-Method:GET
Connection:keep-alive
Host:localhost:9198
Origin:http://localhost:8081
Referer:http://localhost:8081/testRest/test.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Response Headers:
Allow:OPTIONS,GET,HEAD
Content-length:564
Content-type:application/vnd.sun.wadl+xml
Date:Tue, 04 Jun 2013 08:48:28 GMT
Last-modified:B, 04 8N= 2013 20:23:45 MAGST
Here is the request\response if i just put the address of my REST service into browser.
Request URL:http://localhost:9198/helloworld
Request Method:GET
Status Code:200 OK
Request Headers:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie:srmuser=kbar
Host:localhost:9198
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Response Headers:
Access-control-allow-origin:http://localhost:8081
Content-type:application/xml
Date:Tue, 04 Jun 2013 09:10:03 GMT
Transfer-encoding:chunked
Could anyone please help me?

Resources