I have a Polymer webapp initially scaffolded using Yeoman and then deployed to Heroku with the simple following web.coffe script:
gzippo = require 'gzippo'
express = require 'express'
morgan = require 'morgan'
app = express()
app.use morgan('dev')
app.use gzippo.staticGzip "#{__dirname}/dist"
app.listen process.env.PORT || 5000
The problem I am facing is that (at least in Chrome and Safari) every time I deploy a new version I have to clear the browser cache and data to see the changes. Refreshing the page multiple times does not work. However with my local grunt server changes happen as expected in the browser UI.
Where can I start inspecting this kind of problem?
A workaround, same concept that use in this thread:
Force browser to clear cache
is just add a "version control" in your elements on the link import
<link rel="import" href="elements/my-element.html?v=0.02">
It's quite tedius :(
Another kind of Cache that can happen is the service worker cache and had me struggling for a while.
This one if you are on Chrome you need to delete it in dev tools resources tab, there you will see Service Workers on the bottom. Just delete everything (trash on top right).
This is not really related to the question but can help fellow Googlers that may pass by.
Related
On June 21 I changed my website to a new framework. In the past I've used Vuejs and now I'm using React. But my cache never invalidates, I can access my new site only in browsers that never enter the old version or using CTRL + SHIFT + R (But on next refresh the old site backs).
I was looking in the Chrome Dev tools network tool and noticed the response header still sends the date attribute as June 20, others clients have this same problem. How can I resolve this? Without going into browser settings and manually checking my cache, it's impracticable cause older users have this same problem too…
I also tried flush DNS Cache with this tool https://developers.google.com/speed/public-dns/cache
It's running in Google Cloud Run
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.
I'm developing an offline Android app with Genexus Ev3 U9 and when I try the app in the device I see there is no initial synchronization, even when I try to execute a manual sync the app shuts down. The cat log shows that request made to URLs like http://192.168.12.17/MyAppSmartDevicesEnvironment/gxmetadata/MyApp.android.json
worked fine but when the app tries to get this URL http://192.168.12.17/MyAppSmartDevicesEnvironment/rest/MyAppOfflineDatabase?fmt=json&event=gxchecksync returns 404 I tried the same link in my laptop and it's like the requested resource was not created by GeneXus.
What could be wrong?
There are actually a couple of things you might want to check.
When you accessed http://192.168.12.17/MyAppSmartDevicesEnvironment/gxmetadata/MyApp.android.json you got data but that just means that the virtual directory was successfully created. (which is good of course)
Then you need to check if the WCF module is installed correctly, in order to do that you could try to go to http://192.168.12.17/MyAppSmartDevicesEnvironment/MyAppOfflineDatabase.svc/rest or any other service in your KB. That goes straight to the service implementation. (you can check you web.config file in order to see the actual rewriting rules)
If that works it's certainly a URL Rewrite problem like Sandro and Guscarr suggested.
You can download and install the module from here: http://www.iis.net/downloads/microsoft/url-rewrite
Gcastano,
It seems that you're generating to .net, right?
If so, it could be some problem with iis rewrite module.
Anyway you might check gx software requirements...
It seems that REST services cannot be run on your IIS, as Sandro said, try installing URLRewrite.
Further info at http://wiki.genexus.com/commwiki/servlet/wiki?14575,Android%20-%20FAQ%20and%20Common%20Issues
In my Web.API project, for development in the web settings I use the 'Project Url:' of http://localhost/reporter on my local IIS web server. There are pages that are served up from this site using asp.net mvc4 with javascript calls that post to urls like 'api/getdata/'.
For some reason, these have stopped working- for example, I would make a jQuery post to 'api/getdata' and the full URL was http://localhost/reporter/api/getdata which was correct. And life was good.
But now something has changed- same jQuery post, nothing else in code different that I'm aware of, but my full URL's are now http://localhost/api/getdata - I lost that 'reporter' part. I think something may have happened when I deployed this to another internal server- it worked great locally- then I deployed and noticed it didn't work on the new server. And then I discovered that I wasn't working locally anymore.
I've double checked and my project config seems to be the same as it was before...?
I'm sure I broke something, but I have no idea what. Thoughts?
First, I recommend using a tool such as Fiddler or your web browser's development tools to do a network trace and see what the failed request is.
The most likely culprit seems to me to be that the virtual directory is different, or perhaps the browser's URL is different, and that causes the relative path to be resolved incorrectly. Relative paths are generally a very bad thing to use on the client because the client often doesn't know relative to what the URL is.
I recommend adding just a bit of client side code like this:
<script>
var baseUrl = '#Url.Content("~/")';
</script>
And that will declare a JavaScript variable that contains the "root" of the app. Then, elsewhere in the page, you can have code that uses the base URL and appends the rest of the relative path:
<script>
$.ajax(...., baseUrl + "api/getdata", ...);
</script>
Ok so since I applied an SSL Cert to our site the graphs in the dashboard have stopped working. i read this site
EDIT: forgot to add, im trying to get this working in the magento dashboard.
http://www.phpro.be/blog/detail/magento-dashboard-charts-not-working
which states to add "true" to the GetChartUrl() function within
app/design/adminhtml/default/default/template/dashboard/graph.phtml
this works on a site not using SSL.
I then found this site
http://webguru.org/2009/11/09/php/how-to-use-google-charts-api-in-your-secure-https-webpage/comment-page-1/#comment-988
but this supposedly opens up opportunity for SQL injection and other malicious attacks.
next I found this site
http://store.ivvy.ru/blog/chartssl/
and followed the instructions but still the charts aren't working.
i tried changing
const API_URL='http://chart.apis.google.com/chart';
to both
const API_URL='//chart.apis.google.com/chart';
const API_URL='https://chart.apis.google.com/chart';
but neither worked.
Can anyone point me to any other examples / explanations, or explain how to get this working?
Many Thanks
Do you use Firebug or another browser debug tool? If so, what is the error on the Console tab when you load the page containing the charts. I can tell you now, it's most likely due to trying to load a HTTP JS script over an HTTPS connection...which will fail.
Try using their latest API URL which supports HTTPS:
https://chart.googleapis.com/chart