I would like to configure my manifest file so that if a user visits the site while disconnected from the internet or they get disconnected while they are browsing, the next page they visit will be from the appcache. other wise if they ARE connected they will get served a fresh page.
If a given page is in the appcache, and assuming the cache has downloaded to your machine / device, whether you are connected or not, you will see the cached version of that page.
However, if that page is subsequently updated, you can be sure of the user seeing the latest version of it if you trigger an appcache update (i.e. by changing the byte signature of your manifest file). Thus you ensure that your connected users see the most up-to-date content, whilst disconnected users still have content to look at.
Related
While testing images being loaded from an email in my iOS Outlook app, I see inconsistencies with how the app caches them. These images are loading from external sources (i.e. HTML img tag with src pointing to a server, not images that are embedded/attached). The app makes several requests to the same image source as you navigate around. Some of these requests contain the HTTP_IF_NONE_MATCH header but there is a lot of inconsistency. I don't think it's caching them correctly. I've included more details below. it looks like it's causing my image to be loaded several times when the person is browsing the email/their inbox.
The reason this is a problem for me is that I'm building an email tracking tool that relies on a pixel tracker inside the email. I'm trying to determine how many times my email is opened by its various recipients. So this inconsistency is causing misfires for the tool unfortunately. While I realize that could be considered consequential limitation of relying on the app, I'm wondering if the lack of image caching is a larger issue that could be addressed. It is effectively firing requests to load the image repeatedly so that is eating up mobile data unnecessarily.
Is there a way to improve its caching somehow? I'm also looking for any other ways to determine requests coming from the same phone. Here's what I see in my server log when dealing with an email that contains my pixel tracker.
Push notification for email received on iPhone
Click the app to load the inbox -> Tracker request fired for 1st time (i.e. image loaded for first time)
Open email -> Tracker request fired for 2nd time (without any HTTP_IF_NONE_MATCH header)
Go back to inbox -> Tracker request fired for 3rd time but this time it includes HTTP_IF_NONE_MATCH header. Note previous requests did not include this header even though it's the same URL so some inconsistency indicating it did not cache it
Open email for the second time -> Tracker request fired for 4th time but it did not include the HTTP_IF_NONE_MATCH header (inconsistency with 3rd time, which had header)
Go back to inbox -> No request fired
Open email for third time -> Tracker request fired for 5th time and it included HTTP_IF_NONE_MATCH header (so inconsistency between this and 4th request, which did not include it)
From here on, repeating any of the above steps would trigger requests but would always include the HTTP_IF_NONE_MATCH header successfully. I also tested changing folders, refreshing the inbox, replying to emails etc. While this triggered tracker requests as well, they also included the appropriate header.
However, I noticed that closing the app (by swiping it off) and then opening it again effectively caused the behaviour to reset. The 1st, 2nd and 4th requests would still not include the header while the others would. Note the same happens on data vs wifi.
Generally speaking, it looks like the iOS app is repeatedly loading the images that it should have already cached. Outlook desktop clients work great because it only fires 1 request to load the pixel. For the Outlook Android app, it seems to do a better job caching the image. It makes 2 or 3 requests the first couple of times you open the email but the 2nd/3rd requests always include the header. After that, it stops loading the image altogether so it must be caching it on the phone somehow. Since the Android app functions fairly differently, this is what lead me to believe it may be an issue that could be resolved in the app itself. However, as I said above, I'm looking for alternative ways to determine how to track the user.
Another way I normally rely on is to set a cookie to indicate an open just happened by that device. I then simply skip these false positives to avoid the repeated requests. However, because of the nature of iOS apps needing to whitelist third-party cookies of web requests within the code, each subsequent request is not sending my cookie along either. Here's a related question as well. I confirmed the Safari settings do not block 3rd party cookies in case it conflicts.
Alternatively, if there's another way to tell a unique device, I could figure out how to skip repeated opens for that phone on the server. I checked the rest of the request headers. The only thing that's somewhat identifiable is a combination of user-agent and IP address but that seems very unreliable to me. Two people in the same office with the same corporate phone could be on the same wifi so I think that would fire false negatives instead.
Is there another way to determine the device is opening it multiple times? Ideally if it sent a unique identifier or something, that would be very useful.
Is there a way to force the app to cache the image (this would heavily reduce the misfires) via say some response header?
OK, this is weird.
We have a test website (just a payment form) here: http://blog.inglesen100dias.com/
The problem is that everyone I've talked to but me can see the form (our hosting provider, other coworkers in different states/countries, etc). Me, I see a 403 forbidden error, "You don't have permission to access / on this server."
We made a change earlier today in that subdomain, changing the A record to point it to a different server. But for some reason everyone but me can see the new page where it's pointing at.
I've deleted the cache, flushed the DNS (I'm on Windows 8), entered the website with my cellphone (same error)... so I don't know what else to do. My impresion is that when I access that URL, it's still trying to open a location in the old server (where the domain originally pointed), instead of in the new server. Why this only happens to me?
Any advice would be very welcome!
UPDATE
I've turned-off the Wifi in my cellphone (it's connected to the same network as my computer) and now it shows the right page! If I turn the wifi back on, then it shows the 403 error again...
Can it be a problem in the router?
I restarted the router and now it's showing the right page!
I've got (actually my employer has) a mobile website that enables Safari integration (for iPhones and iPads) - meaning that customers can bookmark it to their home screen and then it would behave as a standalone web app (no address bar, custom icon, start-up image etc).
It works all right except that one week ago (coincidentally soon after apple has released iOS 6.1.2) some of our customers (6 of them initially) complained that they no longer get the normal content but a '404 page' of a public wifi provider (The Cloud owned by Sky here in the UK). After a bit of investigation we've figured that at some point those customers connected to the Cloud wifi without actually logging in (it's one of those providers that would redirect you to a login page to enter your credentials, after which you can carry on browsing). The thing is that even after switching back to their private wifi or mobile data connection the application would display the Cloud's page.
This only happens (as far as I can tell) when the application is launched via the bookmark (I couldn't see this behavior when using it from safari).
What happens is that the customers would connect to the cloud wifi (without logging in), they would open the application at which point the router will issue a redirect response to their login page; the application would cache the login page and it will always display it whenever using the bookmark again. (I've performed a capture when this happens and there are no requests being made at start-up whatsoever).
Even weirder, in this situation, if removing the existing bookmark and adding a new one will show you the same cached page (with the whole operation being performed away from the Cloud). We've fixed this by adding a unique identifier to the URL each time we hit the bookmark screen (this indicates that the web apps' sandboxes are linked to the url, which is to be expected).
What we're trying to achieve is to have the application properly recovering after the customer has moved away from the Cloud. But there doesn't seem to be a straight forward way to do this.
Furthermore there's a level of inconsistency in all of this - most of the times when the flow is performed I will see a 404 page (a custom 404 page https://service.thecloud.net/service-platform), but sometimes I would be properly redirected to the login page, in which case the application would not break.
My assumption is that there is a weird race condition in the standalone web app application model causing the browser not to properly handle redirects (and actually caching 404 pages). I've raised a support incident with Apple (which eventually turned into a bug report) but it might take a while and I'm trying my best to figure out a workaround.
Any ideas, maybe someone has seen this before?
The issue is aggravated by the fact that I need to have a 5 minutes walk ever time I'm testing any fixes; I've tried creating simple test forms, but I wasn't able to reproduce the issue, where as with the full app I can do it pretty much every time.
Here's a summary of the steps to reproduce:
Via private wifi (or mobile data connection) add a bookmark to a website (I've managed to reproduce it with quite a couple of apps that support safari integration as described above)
Open the application to review the normal content
Connect to a Cloud hotspot and open the application from the bookmark (open-close it for a couple of times if you don't get the 404 right away)
Connect to the private wifi (or mobile data connection) and open the application via the bookmark -> you'll see the same 404 page again
In the end the fix was to add a unique query string parameter with the initial page request (pretty easy with the setup we already had, via the launcher page). I've filed a bug report with Apple which they've acknowledged by linking it to a previous item. Here's a post on the topic:
http://blog.onos.ro/ios-6.1.2-caching-issue
I'm developing a small HTML5 web application for iPad that is intended to work in fullscreen mode (ie. it has the proprietary Apple meta tag, it is added to Home Screen):
<meta name="apple-mobile-web-app-capable" content="yes" />
The application basically fetches some data via AJAX and presents it to the user. The AJAX data are external (from a different domain, different server). I have the system setup for cross-origin requests, they work in online mode. In other words: the static data lie on server A, the dynamic data - on server B.
I created a proper cache manifest file, listing all static content of the site (HTML, CSS, images, JS) and then having the NETWORK: * section at the end - this way all the dynamic content (AJAX) is always retrieved from the network. The application fails "gracefully" if the requests fail, by displaying some fake content.
With the above setup, the following happens:
If I run the application while online, everything works ;)
If I disable the WiFi on iPad (pure offline mode), everything works as expected - the application falls back to the offline content
If I connect to the network again, but take the static-content server offline (the one that has everything cached), the application won't start; after spending a while in splash-screen, it shows me the a popup with <app> could not be opened because it could not connect to the server.; I can either choose Close or Retry.
The point 3 of the above is the one that drives me crazy because it was the only reason I started fiddling with application cache. Why doesn't the iPad web app fall back to cached content if the manifest file is not reachable? (not 404, the server is offline)
Is the answer to HTML5 iphone offline webapp completely incorrect? If not, how can I achieve this behavior on iPad?
Point 2 and 3 are completely different scenarios, so we cannot expect the same behavior.
In point 3, the device cannot fall back to the cached content when in online mode because if it do so, there will be no way to know for the user whether he is connected to the server or not.
I mean, in offline mode, the user knows it, and knows that he is with cached data. But in online mode, he expects to get the stuff from the server. If the server is not available, the user should be aware of this. If the server is not available and he is sent directly to cached data, the server error will be hidden to him, thinking that he is connected when he is actually not.
For example, web browsers can cache pages to be seen in offline mode. But if we are in online mode and try to open an unavailable page, we expect to see the error message, not a cached version of the page without any warning. We can go to offline mode to see the cached page if we want, but the correct behavior is to show the error to the user.
I have been given a webtrends DCSID number that is liked with my clients webtrends account.
However I have not been given access to the clients account, so I have no way of verifying if the reporting is working.
Is there a way to verify if it is working, e.g. setting up a trial account to test on?
The target is an iPhone app
You can also download an HTTP monitoring tool that will show you everything that is sent to Webtrends when the tag fires. It won't show you what the reports will look like, but testing the tag should really be the first step in any tagging implementation. If the tagging doesn't work as expected, the reports won't work either. :)
Standalone tools: Fiddler (free) or HttpWatch (basic or paid). Firefox Add-on: HTTPfox (free).
To test how the tag fires from an iPhone, you will need to either use a User Agent switcher/spoofer in your desktop browser, or use an actual iPhone and monitor the traffic using Fiddler—here are instructions. Once you install one of these, look for the hits to http(s)://statse.webtrendslive.com/[the client's DCSID]/dcs.gif?etcetera
You can go to https://tagbuilder.webtrends.com and generate the needed files for tracking, e.g. an empty html page and the javascript. If possible, upload both to a test webspace and access the page. Type into the addressbar
javascript:dcsDebug();
and a small popup will appear. You will now see all informations collected by the javascript and what would be send to the SDC server.
If needed, ask your customer to send you the logfiles of the SDC and compare the logs with your activity.