Dev411 Blog

Jim Ley reports on the Google JSON XSS exploit with example code and screen shots of stealing information from the AdSense site. The moral of the story is don't use text/html for the MIME type when returning JSON, use application/json which is an IETF standard (RFC 4627) now. Most browsers should handle application/json fine, however Opera may have problems and you may want to use application/x-javascript for that. Something to remember even if your AJAX code/library doesn't care about the MIME type returned by the server, e.g. Dojo.

If you are using Catalyst and Catalyst::View::JSON, your JSON response will automatically be set to application/json for all user agents except Opera (which gets application/x-javascript) so you're already safe(r).

Two weeks ago, Scott Laird posted a Mongrel patch to the Typo list to make it work with non-root URIs. I'm particularly interested in this because Mongrel is getting more mindshare and my blog uses a non-root URI. The patch has been submitted to Zed Shaw for inclusion but, until it's in, here are some links since I don't think this is easy to find:

• archived email
• mongrel.diff patch

UPDATE: This is now included in Mongrel 0.3.13.4 pre-release.

One of the most valuable assets for a website is its domain name. Whenever I check to see if a new domain I want is available or not, part of me wonders if just the act of looking for domain name would make it unavailable, i.e. if someone is scanning domain name look ups. I've always written this off as being too paranoid but Larry Seltzer reports this is exactly what Chesterton Holdings is doing. Chesterton Holdings' webpage essentially admits they are using an automated shotgun approach to acquire domain names which may result in many names they don't have the rights to:

Larry checks for domain availability on the CNet Domain Search Page (the link provided doesn't seem to go there anymore) and within 30 hours, those domains were registered to Chesterton Holdings. There's some speculation as to how this is happening but it's clear there is a compromise somewhere. I urge everyone to treat domain search aggregators as (the equivalent of) phishing sites and go directly to a trusted registrar for domain availability checking. The other thing you can do is look up lots of worthless and nonsensical domain names to see if Chesterton registers them.

I've been looking for a program that will take full screen shots of web pages even when the web page is larger than the window size on my physical screen, requiring scrolling. This morning I found such a program in Petr Šmejkal's Win32::CaptureIE when it was mentioned by Displeaser on DevShed Forums in the "Screenshot of webpage" thread. It uses ImageMagick for image manipulation.

Many popular sites in the Typo community have chosen not to include www. in their domain name. I was curious about this because it isn't very common in websites overall. Then I ran across a Typo Forums thread saying dropping the www. with a 301 redirect would improve SEO. I wonder if this thread or something similar in the Typo community influenced many of the sites.

Doing a little more searching I found a Digital Point thread where the general concensus is that having www. or not doesn't really matter but you should pick one and do a 301 redirect from one to the other so they don't appear as different sites to search engines. I also checked some high traffic sites in Google to see how they are indexed, e.g. searching on [site:myspace.com] shows MySpace's domain indexed as www.myspace.com. Since dev411.com was indexed with www. already and responding to both dev411.com and www.dev411.com, I simply added a 301 redirect to www.dev411.com.

The following from the Digital Point thread adds a 301 redirect for Apache:

RewriteEngine on 
RewriteCond %{HTTP_HOST} ^yoursite.com [NC]
RewriteRule ^(.*)$ http://www.yoursite.com/$1 [L,R=301]

However, it seems that many sites do not do a redirect and serve content on both www.domain.com and domain.com. MySpace and Ruby on Rails (rubyonrails.org) are two such sites. Although one is preferred, both are responded to with HTTP 200 status. Perhaps the SEO issue isn't as important of a consideration for those sites.

The other consideration when using cookies. If you wish your users to access your website with no subdomain as well as multiple other subdomains, you will need cookies that can work across both uri styles. To set a cookie that will work without a subdomain, set without the Domain attribute. To set a cookie that will work with multiple subdomains set a cookie with a domain that starts with a dot. To cover both bases, i.e. if you wanted to set session cookies that work across different uri styles, set both cookies with the same name.

Edited 16 June 2007 to discuss non-redirecting sites and cookies.

The future of Prototype (the JavaScript AJAX library), both as a stand-alone library and as a part of Rails, is being discussed by the community on the rails-spinoffs list. The primary concerns appear to be:

I just migrated my Catalyst app to use GD instead of ImageMagick based on some reported compatibility issues.

• Chris Laco reported Apache2/mod_perl2 would core dump with ImageMagick (on FreeBSD). He moved to FastCGI+ImageMagick first and is now using FastCGI+Imager. ImageMagick has been reported to work with Mason+Apache1.x+mod_perl1.3.
• Andreas Marienborg reported on #catalyst IRC that Imager doesn't work with Catalyst+PAR and has moved to GD.
• Someone on #rubyonrails IRC mentioned having problems with RMagick and was looking to migrate to ruby-gd

Wanting the best of all worlds, I moved to GD which also has a smaller memory footprint than ImageMagick. I ended up writing my own wrapper for Lincoln Stein's GD module using the Image::Magick API (drop-in replacement for a very limited set of functionality) though something like Image::Thumbnail, which provides a uniform interface to GD, ImageMagick and Imager, is probably better for general use.

Thanks to Chris and Andreas for their reporting issues. Hopefully I'll be all set with GD.

Here are some screen shots of various autocomplete effects in action to show what people are doing. The images and names above the images have links to the relevant sites with the domain name shown. I'll add more screen shots here as I get them. Let me know if there are any other toolkits demos or interesting implementations.

Here are some observations:

• All of the screen shots and links are for toolkits except for Google which is just shown as an example.
• The jQuery and Scriptaculous demos do not automatically display "autocomplete" text in the input element.
• All of the demos, except Dojo, include text that will end up in the input field as well as extra display text that will not.
• Where both simple and customized demos are available, the customized one is used for the screen shot.
• Del.icio.us also has nice variable horizontal location/width autocomplete for tags that I don't have a screen shot for atm. Gmail also has a nice autocomplete that isn't shown.

The observations are just for the particular demos available. The libraries may have the ability to be configured in additional ways.

Dojo (dojotoolkit.org) (fullsize screen shot) jQuery (jquery.com) (fullsize screen shot) Yahoo UI (yahoo.com) (fullsize screen shot)

Google (google.com) (fullsize screen shot) Scriptaculous (script.aculo.us) (fullsize screen shot)

NOTE: The jQuery screen shot has been edited to size it better from the demo page: (a) the number of results was reduced and (b) the width has been reduced because there's a lot of blank space in the demo. The original jQuery screen shot is also available.

UPDATE: CAPXOUS has an interesting paged autocomplete variation which adds Next and Prev links when applicable. The one minor issue I ran into when using this is that it would switch location (above/below the input) if it was near a browser edge and the number of items changed as shown below. I found this a bit disconcerting. I wonder if there's a way to making it always used the side for the larger list? CAPXOUS can also show info that's searched on but not shown but this was less interesting than the paging. One final note, unlike the other JS libraries listed above which are free open source software (FOSS), CAPXOUS is commecial requires a license fee. Pretty interesting idea.

CAPXOUS (capxious.com) (fullsize screen shot)

Damian Conway just posted a message about Perl 6 comment enhancement on PerlMonks. I especially like the nestable feature.

#{ comment 
    here 
}
#[ comment 
    here 
]
#( comment here )
#< comment here >
#« comment etc. »

John Porter asks for an enhancement which I think would be useful:

#<<<
#<{[

Damian replies:

People have editor macros and other workarounds today but this seems much cleaner.

I saw a few other very cool things in Damian and Larry Wall's Perl 6 presentation at YAPC::NA. Just hope Perl 6 comes out sooner rather than later.

I just listened to The Web 2.0 Show, episode 23 with Steven Smith where they discuss Typo and the memory leak problem. This issue was recently solved by Scott Laird for Typo 4.0 and is currently in the trunk. Thanks to Ajay for making me aware of this podcast on the #typo IRC channel.

Here's a transcript of the podcast relevant to Typo for anyone interested (let me know if I got anything wrong). There has been some minor editing to make the text flow better but nothing of substance. If you want to listen for yourself, it's at the 10:30 to 12:30 minute mark. Given the memory leak fix, I'm not sure how much of the performance discussion is still relevant but it's an interesting read/listen.

• Josh Owens: I had a question for you as far as Rails scalability goes. We ran into a problem with one of our servers. We were running Typo actually for The Web 2.0 Show and for the Steelpixel blog and all that stuff; and it just went out of control and all of a sudden we were seeing the Ruby processes were hitting like 300, 400MB each as far as memory goes. Have you guys had any experience tracking down bugs within Rails.
• Steven Smith: Well, I'll be very gentle on the call cause I know it's a podcast but the problem that you experienced was not with Rails, it was with Typo. Not that Typo is a bad blog.
• Josh Owens: No, not Typo, come on.
• Steven Smith: It's used heavily. It was written by Toby, as you know. Toby's kind of moved on. Still a great group of guys working on it so I want to make sure it comes across that we're not saying anything negative about it, but Typo is very resource intensive. Typo tries to do a lot of things as a blog engine. And as a result, I mean they kind of, I don't know if you kind of ever ran it in development mode, for example, under Rails but they advise you really to not even do that when you're doing development. It in and of itself is a very high-powered application so most likely the problems you experienced were more so related to the application than they were to the Rails framework per-se, would be my guess. Because we are investigating blog engines at the moment, and have invested quite heavily in Typo actually, in terms of checking it out, things of that nature. Mephisto is another. It doesn't do near what Typo will do but it's a simple straight-forward blog engine, looks like it's got a lot of momentum behind it and that's kind of what we're looking at right now as well.

Can anyone provide a reference for the recommendation against doing Typo development under development mode mentioned by Steven?

Scott is also working on Akismet itegration for Typo 4.0 to stop comment spam. 4.0 will resolve the following major issues:

• Typo will run on the latest version of Rails
• memory leak is fixed
• spam issues are addressed

Here's a full list of the changes since 2.6.0. With Typo 4.0 on the way, are there still reasons to consider Mephisto?