Simon Willison's Weblog: xmlhttprequest

How do you change page content and URL without reloading the whole page?

2012-02-11T13:25:00+00:00

My answer to How do you change page content and URL without reloading the whole page? on Quora

This can only be done using JavaScript. You use XMLHttpRequest to pull in new information from the server (also known as Ajax - most people use a JavaScript library such as jQuery to handle this) and then use the HTML5 history API, in particular the pushState method, to update the URL.

Sadly pushState isn't supported by IE versions older than IE10 - it's up to you if you resort to fragment identifier URL hacks to support that browser or (my preferred approach) just leave IE users with full page refreshes. Sadly most versions of the Android browser don't support pushState either, and performance constraints on mobile means they are harder to ignore than IE.

Tags: ajax, javascript, jquery, web-development, xmlhttprequest, quora

flXHR

2009-11-26T12:52:16+00:00

flXHR

I was looking for something like this recently, glad to see it exists. flXHR is a drop-in replacement for regular XMLHttpRequest which uses an invisible Flash shim to allow cross-domain calls to be made, taking advantage of the Flash crossdomain.xml security model.

Tags: ajax, crossdomain, flash, flxhr, javascript, swf, xhr, xmlhttprequest

Quoting Iain Lamb

2009-08-18T12:27:31+00:00

rather baffling finding: POST requests, made via the XMLHTTP object, send header and body data in separate tcp/ip packets [and therefore,] xmlhttp GET performs better when sending small amounts of data than an xmlhttp POST

— Iain Lamb

Tags: ajax, get, http, iainlamb, performance, post, xmlhttprequest

Reading binary files using Ajax

2008-04-22T19:02:02+00:00

Reading binary files using Ajax

There’s a simple trick for Firefox, and (amazingly) you can get IE to play along using a function written in VBScript.

Tags: ajax, binary, firefox, internet-explorer, javascript, vbscript, xmlhttprequest

Cross-Site XMLHttpRequest

2008-01-09T23:57:00+00:00

Cross-Site XMLHttpRequest

“Firefox 3 implements the W3C Access Control working draft, which gives you the ability to do XMLHttpRequests to other web sites”—you can mark a document as available for cross-domain requests using either an Access-Control HTTP header or an XML processing instruction.

Via John Resig

Tags: accesscontrol, ajax, crossdomain, firefox, firefox3, http, javascript, john-resig, mozilla, w3c, xml, xmlhttprequest

The Future of Comet: Part 1, Comet Today

2007-12-11T13:13:11+00:00

The Future of Comet: Part 1, Comet Today

Absolutely the best summary I’ve seen of all of the current Comet techniques in one place.

Tags: ajax, comet, iframes, jacob-rus, javascript, long-polling, xmlhttprequest

Ten New Things in WebKit 3

2007-11-16T01:19:52+00:00

Ten New Things in WebKit 3

Does “incremental updates for persistent server connections” for XMLHttpRequest mean Safari now has native support for Comet?

Tags: ajax, comet, javascript, safari, safari3, webkit, xmlhttprequest

Quoting Alex Hopmann

2007-01-24T20:48:17+00:00

Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).

— Alex Hopmann

Tags: ajax, marketing, xml, xmlhttprequest

XMLHttpRequests using an IFrame Proxy

2006-08-01T17:40:02+00:00

XMLHttpRequests using an IFrame Proxy

Another scary hack abstracted away by Dojo.

Via dojo.foo

Tags: ajax, crossdomain, dojo, javascript, xmlhttprequest

The XMLHttpRequest Object

2006-04-09T23:58:44+00:00

The XMLHttpRequest Object

A W3C Working Draft.

Via Mark Pilgrim

Tags: w3c, xmlhttprequest

Understanding the Greasemonkey vulnerability

2005-07-20T03:09:19+00:00

If you have any version of Greasemonkey installed prior to 0.3.5, which was released a few hours ago, or if you are running any of the 0.4 alphas, you need to go and upgrade right now. All versions of Greasemonkey aside from 0.3.5 contain a nasty security hole, which could enable malicious web sites to read any file from your hard drive without you knowing.

Unfortunately, 0.3.5 disables all of the GM_ API functions, without which many of the more interesting user scripts out there simple won't work. This is a temporary measure - the GM_ functions should return in a later release, once the security problem with them has been resolved.

I'm going to explain how the vulnerability works, because it illustrates a number of interesting concepts in both web application security and JavaScript.

Same-origin policy

JavaScript has always enforced a same-origin policy for scripts loaded over the internet. This originally applied to scripting between frames (and iframes): a script loaded from a certain domain is only allowed to access the DOM of other pages loaded from that same domain. The same restriction has been extended to XMLHttpRequest - you are only allowed to make an XMLHttpRequest call back to the domain from which the script was originally loaded.

This policy exists to prevent cross-domain attacks. Say for example you work for a company with an intranet hidden behind the firewall, full of interesting proprietary information. Without the same-origin policy, malicious sites that you visit on the public internet would be able to read information from your intranet, using your browser as the middle-man.

GM_xmlhttpRequest

The GM_xmlhttpRequest API function does not have this restriction - it can load data from any domain. This enables a whole host of interesting user scripts - the most famous of which is probably Book Burro, which shows comparison prices from different online stores for the item you are currently looking at on Amazon, Barnes and Noble and more.

Malicious user scripts could use this feature to steal information from your private intranet, but malicious user scripts could also do all manner of other nasty things - stealing your Hotmail password for example. This is why you should never install a user script from an untrusted source without first reviewing the code.

Restricting API functions to user scripts only

To keep things safe then, it is essential that the GM_ family of API functions can only ever be used by user scripts, not by code running on pages that you have visited. By installing a user script you have declared it trustworthy - but visiting a web page does not carry that contract.

The way the flawed versions of Greasemonkey do that now is simple: the GM_ functions are added to the JavaScript global object (which is the window object), the user scripts for the page are "injected" using dynamically created <script> elements, they run, then the GM_ functions are removed from the global object to prevent scripts on the page from accessing them. This works because Greasemonkey injection and execution happens just before the onload event is fired - which is when most well behaved scripts kick in.

Object.watch()

Here's the clever part: JavaScript 1.5 defines a method of the Object class (which is inherited by all other JavaScript objects) called watch. Watch is extremely powerful: it lets you register some code to be executed when a property on some other object is assigned. This is the key to the Greasemonkey vulnerability - by watching the window object for the point at which Greasemonkey adds the API functions, a malicious script can use those functions at the moment they are attached.

The file:// protocol

Here's the final piece of the puzzle: the file:// protocol in Firefox allows you to view files and directory listings in your browser. Unfortunately, it also allows the GM_xmlhttpRequest function to do the same. It's not at all hard for a malicious script to use the function to load in files at a known location - or even load in directory listings (as HTML), parse them and use them to find all kinds of things scattered around your hard drive.

Solving the problem

The principle problem then is the requirement for "safe" Greasemonkey API functions - that is, functions that can be used by the user scripts but not by code running on a website. Aaron is looking in to this right now - it looks like the solution will require a minor change to be made to many existing scripts, but the trade-off in terms of security is more than worth it. The GM_xmlhttpRequest function will also be modified to disallow file:// URLs.

Until then, 0.3.5 is the only safe version of Greasemonkey.

Tags: greasemonkey, javascript, security, xmlhttprequest

Why the term Ajax is useful

2005-04-19T01:15:58+00:00

Software design patterns are useful mainly because they provide a shared vocabulary: rather than discussing the intimate details of a three layered application architecture, we say "MVC". Rather than describing an object that tracks your progress while looping over a collection, we say "Iterator".

The same is true for Ajax. While the techniques it describes have been around for years, grouping them under a single term is extremely valuable for raising the level of discussion about them. No longer will we have to explain XMLHttpRequest / hidden iframes / crazy cookie tricks in depth when discussing sites which pull fresh information from the server without reloading the whole page. Instead, we can say "Ajax" and move on to more interesting things.

Matthew Haughey says it's all about marketing. I disagree; it's about smarter and more effective conversations.

Tags: ajax, design-patterns, jargon, xmlhttprequest