If a Url is opened on a non-default store, same url do not returned from cache in different browser or even in Incognito mode.
Steps to reproduce
1.Created 2 different store, Store A, Store B (Default store)
2.Enabled full page cache with In-Built Mode.(Using Redis)
3.Open home page on Store A.
4.Open same home page on Store A in different browser or in incognito mode.
Expected result
Home page on Store A, should be rendered from FPC in different browser as it was cached in other browser
Actual result
Page do not return from FPC causing multiple keys in redis.
Related
I am hosting a flutter web app, which involves the initial url having query parameters (e.g. https://mysite.web.app/?k=ZF6K5UA7X3Jk9HJanla3). I use the url_strategy package to get rid of the #, however when the site loads, the query params are stripped off, leaving the bare-boned "https://mysite.web.app". I have got around the functionality aspect by storing the param as a cookie variable, however it is not ideal.
Is there any way to re-instate the params programmatically in the url bar of the browser? The reason for this is for both (i) giving the user the option to share the original URL, and (ii) allow them to add the app to their mobile device screen as a PWA (with the original full url).
Any suggestions welcomed.
I resolved this via the implementation of go_router. With the combination of state.queryParams and Router.neglect(context, () => context.go('/?k=$myOriginalParam')) (from any pages that wanted to go back to the original route with no browser back button history), I can retain the query parameter in the browser bar successfully.
In Chrome Dev Tools > Application under Cookies I see a list of URLs. When I hover over each one, Chrome shows the message "Cookies used by frames from X".
At first, I assumed that frames meant "iframe", i.e. if an iframe was used on this webpage from source X, then any cookie set by visiting that (iframe view of the) site would show up in the dev tools for your inspection. However, I checked to see if there was always a corresponding iframe for each source, and that is not the case.
So my questions in summary are:
what does "frame" mean in this context?
Why are these cookies almost always empty? For example, I'm looking right now at "Cookies used by frames from https://www.facebook.com", and it's empty.
As mentioned in Chrome DevTools documentation:
When you expand the Cookies category, it displays a list of domains of
the main document and those of all loaded frames. Selecting one of
these "frame groups" displays all cookies, for all resources, for all
frames in that group. There are two consequences of this grouping to
be aware of:
Cookies from different domains may appear in the same frame group.
The same cookie may appear in several frame groups.
Here is a more explicit explanation from Mozilla Storage Inspector documentation (although it isn't Chrome, the concept is similar):
Cookies — All the cookies created by the page or any iframes inside of
the page. Cookies created as a part of response of network calls are
also listed, but only for calls that happened while the tool is open.
So, basically, you will see the main document's domain and all its iframes.
About the "empty" frames with no corresponding frame
It is interesting. It is related to the Preload pages for faster browsing and searching example or Page Prefetch or prerendering feature that Chrome has.
This feature is under Chrome settings > Privacy and Security > Cookies and site data.
What this feature does is prefetch links on the page that you are probably gonna click. This allows the page to load a bit faster when accessing it.
If you dig in their docs you will find this:
Prerendered requests will use a ChromeURLRequestContext which has a
new CookieStore interface, but is otherwise the same as the current
profile’s ChromeURLRequestContext. If the PrerenderContents are
discarded without being used, the changes made to the CookieStore
interface go away. Otherwise, the deltas will be committed to the main
CookieStore for the profile. If there is a merge problem, the
prerendered page is discarded and a fresh request is issued.
This means that for the prerendered requests using a different CookieStore - this is the reason that it's empty on your main profile DevTools. It stores the cookies in a different store and merges them to the main store after you actually click on the link.
I have website (https://www.kriscent.com/product/kart-supermarket/). I created PWA of that after that I uploaded it on Play store by using TWA(Trusted Web Activities), App URL is https://play.google.com/store/apps/details?id=in.kriscent.kartlite.
The URL of website always show in app, So I uploaded the assetlink.json (URL: https://www.kriscent.com/.well-known/assetlinks.json).
After uploading the assetlinks.json, When I run my app, the website URL disappeared but when I switched on other link in the app then the URL shows again.
I don,t know what is happening. Please help me if anybody has idea to resolve this issue.
enter image description here
enter image description here
The problem is that, when navigating to a product detail page, you are using a different origin than the one used to open the Trusted Web Activity and that doesn't have Digital Asset Links setup:
When the application is started, it opens https://www.kriscent.com/, which is correctly validated.
When clicking on a product, the user is take to https://kriscent.com/ (without www), which is a different origin, and is not validated in the Android app.
It is possible to get the Trusted Web Activity to work with multiple origins but, in this case, I'd recommend using a single origin for the initial URL and the navigations, as you will be able to take advantage of using the same service worker, browser storage, etc.
When I ask for a page, I see it serialized and stored on disk (and in the 2nd level cache), after it is rendered, so in the detach phase. Also the page itself is stored in the session.
When I ask for the page again, it is found in the session. So the serialized page is not consulted.
When I ask for the page in another session, the page is created anew. I thought that in this case the serialized page would have been used.
So can you give me an example, a scenario, where the serialized page is read from disk (or 2nd level cache)?
See this url trace:
direct your browser to your app:
http://localhost:8080/
Wicket creates an instance of the homepage and redirects to:
http://localhost:8080/?0
direct your browser to your app once again:
http://localhost:8080/
Wicket creates another instance of the homepage and redirects to
http://localhost:8080/?1
now press the back button so your browser requests the first instance again:
http://localhost:8080/?0
The first page instance is now deserialized from disk.
The http session keeps a live reference only to the page which has been used in the last request cycle. Any older pages are only in the disk. If your users use the browser back button then the old instance is loaded from the disk.
A file on the disk is used to store the pages per session. I.e.different users have different files with their own pages. Sharing the files would be a security issue, it is like sharing the http sessions.
Extra info: The disk storage is part of Wicket and used as default persistent storage. WicketStuff-DataStores module provides implementations with Redis, Hazelcast, Cassandra and Memcached. They could be used in case you want the old pages to be available in a cluster of web servers.
I'm building a rails app, and attempting to put multiple Google Static Maps into the view. These maps will always display broken-image placeholders, except it works when I:
-Use firebug to grab the src URL for the map image
-Paste the URL into another browser tab
-Refresh my apps page with the Google static maps
-I can then view a static map for the URL I pasted, but no others, and only for about 1 min.
Any map on the page I repeat this procedure for will then be viewable, for about 1 minute. Then after about 1 min, that map will revert to a broken image placeholder if I refresh the page.
An example URL from my app (without my API Key) is:
http://maps.googleapis.com/maps/api/staticmap?center=Paris%2C+France&zoom=13&size=600x300&maptype=roadmap&sensor=false&markers=color:blue|label:A|Paris%2C+France
Paste (or click) this into your browser, and you see it works. I paste this URL WITH my API key in it into my browser, it works & and my app will show the static map for a limited time, and then after that it will be broken again. If I paste a URL without my API key, this procedure doesn't work. It's like viewing the map in another browser tab somehow caches it momentarily in my browser, and it will then work in my app... but then it will break in a minute. Haven't found any other way to make map images viewable.
Any ideas why this would happen?
EDIT:
This is extremely strange. In an attempt to diagnose this, I did a copy/paste/save of the apps page source containing the broken map images, and put it on a remote server out in the World. In this new totally static page, I got the same result: I see broken placeholder images where the google map pic should be. But after I copy the src URL of the image & paste it in another browser tab, I can go back to the static page, refresh & only that map image appears.
Stranger still (maybe?), it shows up on my localhost app too. It also shows up on a static local copy/paste of the app page source I save as an HTML file.
So, not saying this must be it, but it seems to be a browser caching issue. No matter where the view page is represented, whether local or remote, and no whether it is dynamically generated or static HTML, the original behavior remains the same.
Maybe you are not considering that the referrer is the one who shows the static map. Check these examples:
Static map shown in https://developers.google.com/maps/documentation/static-maps/styling?hl=nl: the referrer is https://developers.google.com
You grab this link (that is already in the url of the URL on bullet 1) https://maps.googleapis.com/maps/api/staticmap?size=512x512&zoom=15¢er=Brooklyn&style=feature:road.local%7Celement:geometry%7Ccolor:0x00ff00%7Cweight:1%7Cvisibility:on&style=feature:landscape%7Celement:geometry.fill%7Ccolor:0x000000%7Cvisibility:on&style=feature:administrative%7Celement:labels%7Cweight:3.9%7Cvisibility:on%7Cinverse_lightness:true&style=feature:poi%7Cvisibility:simplified&key=YOUR_API_KEY and you paste it in your browser: the referrer is YOUR PUBLIC IP.
So it's normal if the link does not work in any browser but it works in a determined web page. This happens when the authorized referrer is only the host of the web.
Consider also that you may be hitting the free limits of displays per day.