This makes use of the new Access-Control-Check header that has been inching its way through standards committes for the past few years. It works like this: 

1. Script running in the browser makes a request for a URL outside the current document’s domain
2. The browser retrieve the requested page and examines the page’s headers for an Access-Control-Check header.
3. If the page does not have an Access-Control-Check header, the browser fails the request and the script never sees the data.
4. If the page has an Access-Control-Check header but the domain(s) listed in the header don’t match the domain of the document making the request, the browser fails the request and the script never sees the data.
5. If the domain of the current document matches the domain spec in the Access-Control-Check header, the browser passes the data through to the waiting request in the script.

Existing web pages are automatically excluded from cross-domain requests.  That is to say, script can request it and the browser will actually fetch the page, but the script will never see the results.  This is slightly different from how older browsers handle cross-domain requests – the request is shut down when the browser notices that the requested URL doesn’t match the current document’s domain, before anything crosses the wire. 

It seems conceivable to me that under this Access-Control-Check scheme, malicious web pages could launch a distributed Denial of Service attack against a particular server using cross-domain requests.  It doesn’t matter that the script never actually receives the data, the damage has already been done by requesting the page from the target server.  Is there any way for the server to ignore such requests?  I don’t know.  I’m sure the standards committees have discussed this at length.

This caveat aside, it’s exciting to see cross-domain support working its way into the major browsers.  I look forward to tinkering with it in IE8.

Check out the video on Adrian’s blog post.  You’ll probably want to download the .wmv directly to view it full screen in your local video player, as the video box in the blog post is far too small to see what is going on on the screen and the Flash player doesn’t appear to provide any way to zoom it up to a more useful size.  Odd.

Found via Ajaxian

Share/Bookmark

Whenever I visit my Google homepage now, I have to wade through 5 or 6 JavaScript error notifications before I can do anything.  I suspect the culprit is the Gmail gadget for the Google homepage, as I continue to get script errors while trying to browse email in-situ on the homepage.  The gmail gadget is also missing scrollbars on long messages. None of these problems are present when using Gmail itself, just when using the Google homepage.

As a developer, I have to have script debugging enabled in my browser.  This enables me to debug my web app code in the browser, but it also has the unfortunate side effect of pointing out JavaScript errors on every site I visit.  It’s surprising how much crappy code is out there in production.  Slashdot has degraded into the pretty much unusable range in recent months, and now the Google homepage / Gmail widget is following suit.

The script errors are not specific to IE.  Firefox 3 also notes 5 critical errors in its error console when navigating to my Google homepage. To Firefox’s credit, recording these script errors in a log rather than with popup dialogs is much less intrusive than IE, but that also means that significant script errors can go unnoticed by developers testing their web apps with Firefox.

The errors are:

Error: _IG_AddCustomEventHandler is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 43

Error: _IG_AddEventHandler is not a function
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 4

Error: _IG_Json is undefined
Source File: http://www.google.com/ig/f/_pVqt4t_Qx8/lib/libviews.js
Line: 1

Error: _IG_Prefs._parseURL is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 78

Error: _IFPC is undefined
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 2

So, to whoever turned on the new code a few days ago for either the Google Homepage or the Gmail widget for the homepage:  Please review your code and fix the crappy script that you’re dumping on us.  Your developer bretheren thank you for a speedy resolution so that we may get back to debugging our apps instead of debugging yours.

Share/Bookmark

 Note that if you do a search for PicLens on CNET, you’ll get two items in the search results:  The first one is PicLens 1.0 beta for Mac Safari, circa 2006.  You want the second one, version 1.6.1 (or later!).  We’ll work on getting that ancient 1.0 beta file replaced with at least the current PicLens 1.5 for Safari.

Share/Bookmark

Scott writes:

Piclens is a fun and addictive way to browse Flickr and other image sites. The only real downside is that Piclens currently doesn’t support the Firefox 3 betas (no real surprise since they are betas), otherwise this would make my list of must-have add-ons.

Not to worry, Scott – we’ve made a couple of trips to Mozland in recent weeks to discuss Firefox 3 tech bits with the Mozilla team.  Just last week, CoolIris gave a brown bag presentation of PicLens to the Moz lads and lasses in Mozilla’s recently revamped theater/lounge.  There were oohs and ahs in all directions – the CoolIris guys were wowed by Moz’s mile-wide projection screen, while the Moz folks were wowed by what we were projecting onto it. 

Can’t say any more than that at the moment.  Stay tuned!

Share/Bookmark

While zooming around in images on the 3D wall, hit Tab to select the Search box in the top right corner of the screen (or mouse click on it).  You’ll see the traditional vertical bar edit insertion caret / cursor ready for input as well as half a dozen search engines listed below the search box: Google Image Search, Yahoo Image Search, Flickr, DeviantArt, PhotoBucket, and SmugMug. 

Type your search term, say “Giant Squid”, and press Enter to activate that search on the currently selected search engine.  The Wall will begin populating with image results immediately.  Click on another search engine and PicLens will issue your search query to that engine immediately. 

This makes it pretty darn easy to flip between search engines to see how the same terms can return vastly different image results.  Google image search will give you very literal results – generally photos of large squids laid out on the pier or parking lot.  DeviantArt or Flickr, on the other hand, are much more likely to return more artistic images, paintings, or face shots of a guy named “Squid”.  Let us know if this sort of search domain-hopping is useful to you.

In addition to text editing, this week’s PicLens release has several new features: 

• Text display
• Text editing (for Search)
• Search
• Improved image quality in Flickr thumbnails on the Wall
• Improved integration between PicLens Lite and PicLens
• Multi-page RSS support
• View in PicLens photo galleries on your local hard disk generated by PicLens Publisher 
• Did I mention text?

Sharper Flickr Thumbnails 

We’ve stepped up the size of thumbnail images we ask for from Flickr.  This results in much sharper images in the wall, but the cost is it takes longer to downoad them.  Let us know what you think of this (in comments on this blog or in email to feedback (at) piclens.com) - is it too slow for you, or is it the right thing to do for best picture quality?  It definitely looks great.

Multipage RSS

One of the drawbacks to the early uses of RSS was that RSS was never intended to be a permenant record or to contain endless amounts of data.  It’s a simple file format.  If you put a lot of data into an RSS feed, everybody has to download the entire RSS feed to see any of it.  Blogs deal with this by “aging” the items in the RSS feed – old items are removed from the end when new items are pushed onto the front.  Archives are broken down by month, so that each archive RSS feed doesn’t get too big to handle.

This doesn’t work so well for huge image databases like Flickr or DeviantArt.  Flickr actually does provide an RSS feed of a user’s photo stream, but it is restricted to the 20 most recent items.  20 is a lot for a web page, but it’s a drop in the ocean for PicLens.

Austin was poking around in RSS for some other PicLens work when he stumbled upon a bit of esoterica that got him really excited.  Not the photos returned by a particularly curvy search query (though those do excite him as well), but a technique to encode a reference to previous and next pages of an RSS feed in the RSS feed.  Essentially, you can make a really big RSS feed out of a linked list of smaller, more manageable RSS feed chunks.  This is a great solution to the problem of managing large amounts of data in bite sized chunks that can be loaded only when needed.

PicLens Publisher would be a natural to emit multipage RSS.  We will certainly bring up multipage RSS as a site suggestion when chatting with big sites like Yahoo, Flickr, DeviantArt and others.

View Local PicLens Publisher Galleries

An eleventh hour addition to this PicLens 1.6.1 release is the ability to view galleries generated by PicLens Publisher on your local hard disk.  In Firefox, just do File: Open File and select the gallery.html file from the directory created by PicLens Publisher.  Viola! You can preview how your gallery will look in PicLens before uploading the files to your web server.

There are some additional angles on this feature but we’re still fine tuning it so I’ll save that for another day.  Besides, if I spill all the beans at once, where’s the air of mystery and adventure in that?  ;>

Share/Bookmark