I have a page cache running (Varnish) and the VCL sets the X-Cache header to HIT or MISS when it delivers the page. While I'm debugging, I get tired of finding the page headers in my browser to see if the page was a hit or miss; I would like to have the page background (or border) change.
Varnish won't let me modify the body, just the headers and cookies.
I could change the VCL to set a cookie, and then implement some Javascript in a plugin to check the cookie and change the background... yet I feel there must be a more elegant way to do this.
Has anybody done this sort of thing before, and how did it work out?
I suppose that somewhat more elegant way would be to send the styles using Link header. This will not involve sending the cookie or using Javascript.
But that would work with Firefox only:
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "cached";
} else {
set resp.http.X-Cache = "uncached";
set resp.http.Link = "</miss.css>;rel=stylesheet;type=text/css;media=all";
}
}
You're going to experience 'race conditions' with the cookie approach because that state is shared among all tabs browsing the site. The best approach would be:
Store a hit / miss flag in req.http.whatever.
Include a ESI fragment in all your pages (e.g. /color-hack.html).
Add VCL logic to catch /color-hack.html requests during vcl_recv, jump to vcl_synth, and generate some HTML or JavaScript depending on the value of the flag in req_top.http.whatever. Then you can use that in the client side to change the color of the pace of whatever you want to do.
I know it looks a little bit convoluted, but it should be simple to implement if you are familiar with ESI & synthetic responses.
Related
I want to prevent JavaScript redirects in Firefox for one domain (youtube.com), and I was wondering whether there's a plugin that will do it. I'm trying to use NoScript, and I'd like to allow scripts globally because I don't want to disable most JavaScript, but this seems to just allow JavaScript redirects. Is there a way for me to just disable JavaScript redirects (or ideally, display a prompt)?
The only other way I can think of doing it is to write my own extension that messes around with window.onbeforeunload and window.unload, but ideally I'd like to use an existing addon.
var {utils: Cu, classes: Cc, instances: Ci, results: Cr} = Components
Cu.import('resource://gre/modules/Services.jsm');
var myobserve = function(aSubject, aTopic, aData) {
var httpChannel = aSubject.QueryInterface(Ci.nsIHttpChannel);
if (httpChannel.loadFlags & Ci.nsIHttpChannel.LOAD_REPLACE) {
//its a redirect, lets block it
httpChannel.cancel(Cr.NS_BINDING_ABORTED);
}
}
I use the presence of flags to test for redirect. Here are some notes i took on flags awhile back, im not totally sure of how accurate these notes are:
if has LOAD_DOCUMENT_URI it usually also has LOAD_INITIAL_DOCUMENT_URI if its top window, but on view source we just see LOAD_DOCUMENT_URI. If frame we just see LOAD_DOCUMENT_URI. js css files etc (i think just some imgs fire http modify, not sure, maybe all but not if cached) come in with LOAD_CLASSIFY_URI or no flags (0)
note however, that if there is a redirect, you will get the LOAD_DOC_URI and the LOAD_INIT_DOC_URI on initial and then on consequent redirects until final redirect. All redirects have LOAD_REPLACE flag tho
note: i think all imgs throw http-on-modify but cahced images dont. images can also have LOAD_REPLACE flag
Of course to start observing:
Services.obs.addObserver(myobserve, 'http-on-modify-request', false);
and to stop:
Services.obs.removeObserver(myobserve, 'http-on-modify-request', false);
I would like to disbale the X-Frame-Option Header on client side on Firefox(and Chrome).
What I've found:
Overcoming "Display forbidden by X-Frame-Options"
A non-client side solution isn't suitable for my purpose
https://bugzilla.mozilla.org/show_bug.cgi?id=707893
This seems to be pretty close. I tried creating the user.js in the profile dir with the code user_pref("b2g.ignoreXFrameOptions", true);
but it didn't work. The second last entry seems to imply compiling ff with modified code? If this is the case, it's also not a possible solution for me.
I just wrote a little HTML Page with some JS that loops a list of YouTube videos by successively loading them into an iframe. I know youtube supports playlists but they suck and I dont want to download the videos.
Also, it would be nice if the browser only ignores the X-Frame-Option for local files. This would somewhat minimize the security hole I tear open by disabling this. As for Chrome, a solution would be nice but isn't that important.
I guess another approach would be to intercept incoming TCP/IP packets which contain a HTTP Respone and remove this header line but this is quite an overkill.
[edit]
Using youtube.com/embed is a bad workaround since a lot of videos dont allow to be embedded...
This can be easily achieved using an HTTP Observer through a Firefox extension. That observer will look something like this:
let myListener =
{
observe : function (aSubject, aTopic, aData)
{
if (aTopic == "http-on-examine-response")
{
let channel = aSubject.QueryInterface(Ci.nsIHttpChannel);
try
{ // getResponseHeader will throw if the header isn't set
let hasXFO = channel.getResponseHeader('X-Frame-Options');
if (hasXFO)
{
// Header found, disable it
channel.setResponseHeader('X-Frame-Options', '', false);
}
}
catch (e) {}
}
}
}
You can find further info such as how to install the observer on MDN[1][2]
[1] : https://developer.mozilla.org/en/docs/Observer_Notifications#HTTP_requests
[2] : https://developer.mozilla.org/en-US/docs/Setting_HTTP_request_headers#Registering
Using diegocr code, I've created an Firefox add-on to allow the displaying of webpages that have X-Frame-Options in their header, so they will be displayed when accessed via an iframe. It can be downloaded/installed here: https://addons.mozilla.org/en-US/firefox/addon/ignore-x-frame-options/
The Firefox extension mentioned by René Houkema in the other answer no longer works anymore so I created a new one.
https://addons.mozilla.org/fr/firefox/addon/ignore-x-frame-options-header/
This extension is also compatible with Quantum.
Source & updates:
https://github.com/ThomazPom/Moz-Ext-Ignore-X-Frame-Options
This is a very similar question to AJAX, Subdomains and the 200 OK response (and JavaScript Same Origin Policy - How does it apply to different subdomains?), but with a twist. I have a situation in which:
A domain (www.example.com)
Where the page at a subdomain (sd.example.com/cat/id)
Needs to make ajax-style requests to another subdomain (cdn.example.com)
In contrast to the aforementioned question, what I am requesting is images.
GET requests of images (using jQuery $.load())
This seems to be working just fine. Because it was working just fine, when someone pointed out it was generating errors in Firebug the same-origin policy didn't immediately occur to me.
Images ARE loading at localhost (apache VirtualHost url of test.sd.example.com/cat/id)
However, now that it has come to mind thanks to that question I linked, I am concerned that this will not work reliably in production.
Will this continue to work in a production environment -- and will it work reliably cross-browser?
Answer: No -- it only looked like it was working; it wasn't really
If not, how do I fix it? (I don't think I can JSONP images...can I?)
Answer: Continue setting src of image & wait to show until load event triggered.
If so, how do I stop the Firebug errors? If I can. (They're scaring fellow devs.)
Answer: Same as above -- get rid of step where actually doing GET request for image file.
Initial Code
function(imageUrl, placeTarget){
var i = new Image();
var img = $(i);
img.hide()
.load(imageUrl, function(e){
// console.log("loadImage: loaded");
placeTarget.attr("src", imageUrl);
return true;
})
.error(function(){
// error handling - do this part
// console.log("loadImage: error");
return false;
});
return;
} // loadImage
Why not insert the images into the page by creating image elements and setting the src. what could be simpler?
edit: ... via javascript
I'm not sure this is exactly right, but in jquery:
img = $('<img>');
img.attr('src', 'http://somewhere.com/some_image.jpg');
$('#place_to_add').append(img);
img.ready(fade_into_next);
Checkt this post: JavaScript Same Origin Policy - How does it apply to different subdomains?
Does teh whole page reload when this is set to false?
My main question is what the asynchronous does. yes i know what the word means but what does it do in code?
xmlhttp.open("GET","ajax_info.txt",true);
The word "asynchronous" is best described as "done in the background" in this context. It means that if you set this parameter to true, the request will be sent in the background and the user will be able to continue interacting with the page. If you set it to false, the page will BLOCK and the user won't be able to do anything until the request returns.
Note that this is different from the whole page reloading. The amount of traffic going over the wire is still much smaller than the whole page reload, so many of the AJAX benefits are preserved.
One reason why you might want to use synchronous (blocking) AJAX requests is when there's nothing to really do on the page while the request is loading.
BTW, since we're already on this subject: I encourage you to use a javascript framework for your AJAX needs. jQuery is fantastic. Don't use the XMLHttpRequest object directly.
Having used jQuery's ajax I found some issues with IE compatibility, so if you have to support IE6, it may be a good idea to avoid that and use straight JS.
Here's a good tutorial on it:
http://daniel.lorch.cc/docs/ajax_simple/
It's pretty nice to sort a dataset by a number of filters and get the results shown instantly, right?
My solution to do this would be to POST the "filter" (read forms) parameters to a page called dataset.php, which returns the appropriate dataset in compiled HTML, that can be loaded straight into my page.
So, besides this being a total no-no for SEO and for people having deactivated Javascript, It appears as a quite good solution to easily build on in the future.
However, I have yet not the experience to consider it a good or bad overall solution. What should be our concerns with an AJAX-fetched dataset?
So, besides this being a total no-no for SEO and for people having deactivated Javascript, It appears as a quite good solution to easily build on in the future.
Not entirely true, there are solutions out there like jQuery Ajaxy which enable AJAX content with History tracking while remaining SEO and javascript disabled friendly. You can see this in action on my own site Balupton.com with evidence it's still SEO friendly here.
However, I have yet not the experience to consider it a good or bad overall solution. What should be our concerns with an AJAX-fetched dataset?
Having Ajax loaded content is great for the user experience it's fast quick and just nice to look at. If you don't have history tracking then it can be quite confusing especially if you are using ajax loaded content for things like pages, rather than just sidebar content - as then you break away from consistency users are experienced with. Another caveat is Google Analytics tracking for the Ajax pages. These shortcomings, those you've already mentioned as well as some others mentioned elsewhere are all quite difficult problems.
jQuery Ajaxy (as mentioned before) provides a nice high level solution for nearly all the problems, but can be a big learning curve if you haven't worked with Controller architecture yet but most people get it rather quickly.
For instance, to enable history trackable ajax content for changing a set of results using jQuery Ajaxy, you don't actually need any server side changes. You could do something like this at the bottom of your page: $('#results ul.pages li.page a').addClass('ajaxy ajaxy-resultset').ajaxify();
Then setup a Ajaxy controller like so to fetch just the content we want from the response:
'resultset': {
selector: '.ajaxy-resultset',
request: function(){
// Hide Content
$result.stop(true,true).fadeOut(400);
// Return true
return true;
},
response: function(){
// Prepare
var Ajaxy = $.Ajaxy; var data = this.State.Response.data; var state = this.state;
// Show Content
var Action = this;
var newResultContent = $(data.content).find('#result').html();
$result.html(newResultContent).fadeIn(400,function(){
Action.documentReady($result);
});
// Return true
return true;
}
}
And that's all there is too it, with most of the above being just copy and pasted code from the demonstration page. Of course this isn't ideal as we return the entire page in our Ajax responses, but this would have to happen anyway. You can always upgrade the script a bit more, and make it so on the server side you check for the XHR header, and if that is set (then we are an ajax request) so just render the results part rather than everything.
You already named the 2 big ones. Now all you need to do is make sure all the functionality works without javascript (reload the page with the requested dataset), and use AJAX to improve it (load the requested dataset without reloading the page).
This largely depends on the context. In some cases people today may expect the results to be delivered instantly without the page refreshing itself. It does also improve overall user-experience - again, this largely depends on the context.
However, it does also have its pitfalls. Would the user have a need to return to the previous pages after the ajax content was delivered? Since this may not be as simple as pressing the Back button in the browser.