iPhone not caching Asp.Net pages - iphone

If I create a basic asp.net application and set the #outputcache the page is cached fine in chrome & IE on the desktop. First request returns 200, subsequent request return 304 for the default.aspx. (I'm monitoring through fiddler)
However accessing the same page from an iPhone I noticed that it's always returning 200 for the aspx file. All resources are being caching and are returning 304's. So it's just the aspx page.
Any ideas why this is happening?
Some technical details:
<%# OutputCache Duration="30" VaryByParam="None" Location="Any" %>
Stock standard ASPX page. Content-Length: 2464
Reloading on the iPhone using refresh control or keyboard "go" doesn't make a difference.
Explicitly setting eTag does not make a difference
Last-Modified is set
but If-Modified-Since is not being send for the ASPX page
Latest IOS 4.3.1
IIS 7.5 running on Win7 using ASP.NET 4

I think I figured it out. Feel free to correct me however. Website caching is a very messy area.
The root of the problem is that the iPhone is not sending "If-Modified-Since" headers with it's requests. Without that the server cannot reply with a 304.
After some experiments I've found that if you use a link to navigate to the page it will send the 'If-Modified-Since' header and everything works as expected and the server neatly returns a 304.
Cases where it does not send a "If-Modified-Since" even though it's cached:
Typing in the URL
Pressing the refresh button
Selecting the URL and pressing Go
Opening as a bookmark
Opening from a saved reference on the home screen
It only seems to be doing this for the primary url everything else that is referenced does have a "If-Modified-Since" header (where applicable).
Note: I've tested this on IOS 4.3.1 only. Looking at the link Paddo send and further investigation into that area it seems that Apple likes to change caching behaviour between IOS versions.

Found this, re php (will also apply to .net)... iphone doesn't seem to cache any resource over 15k in size, and total cache size is 1.5MB. Note this is old information so may have changed.
http://www.phpied.com/iphone-caching/
The solution for a file over 15k, is to use an offline application cache manifest file, as outlined here:
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/Client-SideStorage/Client-SideStorage.html
PS I know your content length is below 15k - so something else must be amiss... but I'm still hopeful that the manifest file will work.

for ASP.NET just use
Response.AddHeader( "Cache-Control","no-cache");
or
Response.AddHeader( "Pragma", "no-cache");
or
Response.Cache.SetCacheability(HttpCacheability.NoCache);

Related

Facebook App Not Displayed Insecure Content Message In Chrome

I've been trying to get to bottom of this problem for a few hours but I can't seem to fix it, I've seen other questions similar to this and tried to use those to implement a fix for my problem but to no avail.
I've built a facebook contest canvas app which displays fine independantely but when I link it to a facebook page (as a link to a new contest) chrome no longer displays is and gives the following warning:
The page at 'https://www.facebook.com/contest/app_xxxxxxxx' was loaded over HTTPS, but ran insecure content from 'http://mydomain.com/': this content should also be loaded over HTTPS.
I've learned partly by trawling this site that the chrome security is fussier, and the app loads correctly, without errors in FireFox and IE but I can't find any resources that are loaded from a non https source.
I have been through with firebug checking in the net tab and checked that all of the loaded resources are using https (the png images, the jpg images, the css files and the jquery js files which are all hosted on the same server that has the certificate), I have even tried hosting the transitional dtd doc itself but nothing seems to make the warning go away and the app display correctly.
In the other similar questions it seems that there are either resources sourced from non-https sources or there are ssl switches used in the javascript library for facebook passed before the fb init.
The problem is that I am using only the php sdk not the js one (although I am using version 1.9 of jquery, hosted on my server) and I could find no similar ssl specific settings there.
If someone could give me a tip about how I could investigate further, what I might be missing or is familiar with this issue I'd be interested to hear about it.
Thanks a lot.
David
Facebook requires the app to come from https:// you need an ssl certificate on your server and to enable ssl. in the Facebook app settings change secure url to https://mydomain.com url
I did have a similar issue recently (but it only caused issues on IE10) and I resolved that by adding P3P header
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT');
Found the solution!
In the facebook app settings, if the page tab url is specific to a page e.g. https://www.mydomain.com/index.php, chrome doesn't complain with the insecure content message but if you reference a directory the error is propogated. I found this confusing since the 'canvas' urls need to be directories.
I hope this answer will save someone a few hours! :)

Where, exactly channel url is used?

On what browsers or user agents that channel URL is actually used, and what for?
I have no intention of having my site to work on Internet Explorer <= 8 (it is an HTML5 <canvas> game, and I am serving everything else as "application/xhtml+xml").
So, if channel is only useful on that old crap, I can gladly get rid of it...
Related (possibly): Channel URL Facebook
Because the social plugin is cross domain call, it needs a way to communicate. The wrokaround is to include a hidden iframe in the page for that. But, with this workaround, that iframe is loaded every time when page loads and will double the traffic reported. This is why channel url was done. What it does, it load the fb js in that page, and from that moment on, the js is available on your domain.
It will improve your loading times (cache) and will fix the reporting issue (you will see in reports channel page reported separately). But is not necessary for any html5 capable browser.
So, if you are using only HTML5 capable browsers, you are safe to ignore that. I am not sure about ie9, I will try to test it with my app by removing channel url and let you know.
Edit: By removing the channel URL from my app, I start getting double traffic reports from IE9. I think that is a good idea to keep the file there, is is just a simple html file with a single line. Better to be safe than sorry.

Page renders on browsers but throws "404 page not found" for SEO crawlers and/or requests made by program. What could be the issue?

I built a site out of ZF and installed it fine on my server. I have the MVC structure and use custom routing (for SEO purposes) as below:
mysite.com/controller.html
mysite.com/controller/action.html
Generally, everything is working fine but the only problem is that SE crawlers won't find any .html files. If i open the "Activity" window from Safari, I see all the css and other files being referenced/read fine but not the page itself.
So, the page renders fine on a browser but SE crawlers or any program that made the request won't find the page. I'm wondering if it's an Apache issue. My .htaccess file is the same file that shipped with the ZF.
I really appreciate any advise/suggestions/comments!
Is it possible that your app is serving all pages with a 404 status code? So browsers and crawlers are getting the same thing, but the browser will render the content whereas the crawlers ignore it. I've seen some people use the Error Controller in ZF as a way of doing routing (not a good idea), where the Error Controller 'catches' all requests and then examines the params to determine what to display.
If this isn't your problem please could you edit your question to include:
How it is you know that crawlers are getting a 404
Some more info on how you are doing your routing
Also if you can provide an example URL we can check the headers that are being returned.

Facebook graph api picture loading problem

I'm having this very unusual problem where on a page refresh all profile pictures that loaded on the previous page refresh no longer load. Instead each image laoded causes these errors in the console:
Resource interpreted as Image but transferred with MIME type text/javascript.
Failed to load resource: the server responded with a status of 400 (Bad Request)
Especially weirdly is, if I go on one page where I have say, 3 pictures A B and C. If on the next page I have 5, including A B and C from the last, only D and E will load. If I then refresh only A, B and C will load. This can be repeated forever!
Any ideas as to what on earth explains this?
PS. Not linking my app to start with as I don't believe it's necessary, but if needed I will do.
as loading profile pic via graph api is actually an in-direct way, problem will occur if facebook svr cannot handle your request (giving you the actualy pro file location).
I would suggest getting the static link to the user's profile pic via fql/graph api first and then use it in your app. This will actually boost up your app's performance too (displaying the profile pic via graph api is slow).
This is a temporary Facebook issue and has already been reported by at least two other users and logged with Facebook.
I've been seeing the same issue. And this is not the first time. My solution has been to cache the URL which the graph API redirects to. Never had problems with this URL (hosted on a pretty reliable CDN).
I've encountered this issue with alternating bad requests on profile pictures just now: at a closer inspection of the request header and answer headers, I've found the hint that Facebook doesn't allow P3P queries (not anymore? I thought it worked on my last app).
So, if you have somewhere a statement like
header('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"');
just remove it, and perhaps after clearing the browser cache and/or web framework cache, then it should work (if this was indeed the problem, and not coincidentally some Facebook bug).

How does MS-Word open a hyperlink?

I have an MS-Word document with a hyperlink. The hyperlink points at an authentication redirector on my server. When I control-click on the hyperlink, my server logs report that it
does a fetch with IE, then
fetches the redirect url with IE, then
launches the "default browser", which is Firefox in my case, and re-fetches the second (redirect) URL.
What gives? Is this by design?
I noticed this because my auth system is currently dependent on cookies set by the redirector. I have some ideas about using url-based auth for this bit, but I need to know what is motivating Word's behavior first.
I have some guesses but I'm looking for something authoritative (or at least a better-informed guess).
Unfortunately, yes. And they try to blame it on "a limitation of the single sign-on system used by the web server"...
http://support.microsoft.com/kb/899927
Actually, this is a "feature". If the hyperlink is to a Word document, word will attempt to download the document and open it. (You must be thinking it's IE because of the user-agent, but the request is coming from WinInet in the the Word process.)
The mess comes about when the server doesn't respond with a page, but rather responds with a redirect and cookies. Word follows the redirect to see if it's going to get a Word document, and it eventally ends up with an HTML page. It then decides that Firefox should display it, so it launches Firefox with the final redirected URL, (but without any of the cookies that the server sent).
Firefox may end up needing those cookies, if this is an SSO sign-on.
Late addition:
Noticed the same problem. Here with MVC 4 it caused the loss of querystring information.
Word launches the browser only after it receives a Http 200 status.
So I avoided this by checking in the controller whether the request comes from IE7 (representing likely only to be MS Word) and returning a 200 manually.
Then the 'real' browser will re-send the http request and all's well ends well, since from there the request is processed normally and all information is retained in the session with the 'real' browser.
Bit of a workaround, but hey, it works. And it's only for a small amount of requests (in our case).