The negative story hammers Chrome for not supporting Android apps. This isn’t surprising given the rumblings that Google prefers web apps over android apps. its hard to say where things will be in 3-5 years, but if WebKit does evolve to the point where it performs as well as native Android apps, then it makes sense to abandon Android apps, especially if Android doesn’t become the dominant platform. Assuming a split between the iPhone and Android (and perhaps WebOS or Windows Mobile, HA!) and a web app performs well on both (and supports all the native phone features), why bother writing apps for just one platform? If web apps can’t easily do what native apps can, Android functionality can always be added to Chrome OS at a later date, even by someone outside of Google, thanks to the wonders of Open Source. I can’t imagine it would be that hard to launch a Java Virtual Machine, with the Android Activity rendered to a panel in Chrome OS, I’m just not sure that it fits in with the goal of Chrome OS. And really, when are people going to stop freaking out about the stability or reliability of an Open Source project, just because anyone can change it or make their own derivative or find flaws in the program. (All of those are good things, btw.. given that proper controls are in place). Open Source is an advantage, not a liability.

Also, a big limitation of mobile phones is its lack of any real processing power. Up until when I finally rooted my G1 a few months ago, I was under the impression that the web browsing was slow on my device due to latency or bandwidth on T-Mobile’s 3G network. That is until I tethered my laptop and was able to get 600KB/s download speeds and web pages rendered with images almost immediately, while 10-15 second page load times are common. I have to presume it’s WebKit rendering the HTML that is slow with limited processor and memory. So, there’s a fundamental difference between mobile devices and actual computers. Perhaps they will converge over time, but there will need to be some breakthroughs in power consumption of more powerful processors.

What’s interesting in the positive story is all of the negative comments by people who just don’t get it. For even more fun, check out a negative post’s comments from July. Chrome OS is about FAR more then just a web browser. First, Chrome OS moves everything to the Cloud, for better or worse. Assuming we trust Google to not lose or snoop our data, I don’t have a problem with this as it’s benefits are far outweighed. Imagine losing your laptop and being able to sign in to another ChromeOS device (replacement, friend’s laptop, coffee shop, etc.) and instantly have access to all of your data. Of course, this assumes that Google is going to provide potentially hundreds of GBs of storage for your videos, photos and music. Perhaps their strategy is going to be to leverage YouTube and Picasa Web Albums.

Also, people are panicked over Chrome OS being “just” a browser. First off, they are acknowledging that this isn’t going to be targeted at Power Users (ie, most of TechCrunch’s audience) but rather at the vast majority of “regular users”. Google stated that they have a LONG list of use cases that they want to implement. Many of those cases are already satisfied by existing web apps for things like emails or calendars. Its not hard to conceive Chrome OS recognizing USB devices and accessing photos or videos on a camera or phone, and music on a MP3 Player or phone… and syncing those with the laptop and conversely up into the cloud to the appropriate services.

I think many people would be amazed at what some web apps are capable of now. Photoshop is often pointed to as a necessary app that people need on their computers. Really? If you are a graphic designer, then sure… but Chrome OS isn’t directed towards you, at least not for advanced graphic work. I really doubt that many people use Photoshop for more then cropping, rotating, watermarking, or minor corrections like red eye or color levels. A quick web search turned up several web apps that are up to those tasks, and a year from now they may have even more functionality.

And, for all the concerns about requiring an active Internet connection, remember that HTML5 includes offline storage and even without HTML5, projects like Gears (among others) provide for offline access. Gmail has had offline access for about a year now. Chrome OS devices will have plenty of storage to mirror your data that is in the cloud. There’s no reason that these web apps can’t be accessible as offline applications, syncing your data up to the cloud automatically when you next get an internet connection.

And finally, the biggest reason why I think Chrome OS is a big ball of awesome… It’s Linux. Yes, people railed on Google about it not really creating anything new. Its Chrome on Linux with some other glue. Saying that isn’t an OS is like saying that Ubuntu isn’t an OS since its based heavily on Debian. And, Chrome on Linux IS a new thing. Chrome started as a Windows App. That makes sense as there are MANY Windows users, so it is a brilliant move as it exposes those windows users to a superior browser and allows Google to work out its issues and add features. Its a great way for Google to get their foot in the metaphorical door. Some choices were made to make it easier to port to other platforms, like using Skia rather then GDI. Clearly google planned on Chrome running on more then windows.

So, yeah.. the Chromium project has been making great progress and Chrome has been usable on Linux for some time now. Yes, it makes me a little bit happy to see this as an opportunity for someone to hand Microsoft some stiff competition (since Apple priced themselves out of that role). But, the REAL thing to be excited about it the fact that if Chrome OS is even mildly successful, it means that there may finally be a critical mass of Linux users. So, finally there will be a real reason for hardware manufacturers to provide Linux support. Support has been pretty good from the likes of Intel, Nvidia and ATI/AMD for graphics drivers. But things that are clearly lacking are low level things like power management, suspend/resume, some wifi-drivers, etc. Having Google working with hardware manufacturers means that the rest of the Linux community will benefit greatly. Hopefully, the days of buying a laptop and hoping that all your hardware will be well supported will soon be gone for good!

It will definitely be an interesting year or so! I, for one, will be eagerly awaiting to see how this all plays out.

Here’s the situation.. we have a legacy Classic ASP site that we are moving to more scalable and stable environment… Since we want to have multiple web servers handling the load during peak hours (it runs just fine on one right now) and be able to perform new releases along with testing during off peak times while the website continues to run on one server. This also means that we can easily throw more webservers into the mix should that be necessary later.

The easy (and open-source and free) solution is to use Apache as a reverse proxy.  This also allows for some other neat tricks (mod_security, mod_deflate) without having to deal with Windows and IIS configuration.. or make any code changes for that matter.

The problem comes in with how Classic ASP deals with cookies. Deep in the bowels of ASP, Microsoft was benevolent enough to add in HTML encoding of your cookie’s name and value. This actually isn’t a horrible thing as it prevents some poorly written code from creating an exploitable bug (HTTP Header injection), but its a bit overzealous and there’s no way to alter its behavior. You’re simply stuck with it.

Of course, if you’re happily writing ASP code, it gets encoded and decoded for you so you never even know its going on.

ASP Code to set a cookie:

Response.Cookies(”SERVERID”) = “balancer.www2″

ASP Code to display that cookie:

Response.Write “Cookie: ” & Request.Cookies(”SERVERID”)

Outputs:

SERVERID: balancer.www2

The problem lies in what is actually being sent by IIS:

Set-Cookie: SERVERID=balancer%2Ewww2; path=/

%2E is simply an HTML Encoded period. I’ve never known a period within a string to cause a security issue… but it gets encoded anyway. Apache’s mod_proxy_balancer looks at that cookie and expects to find a period within it, using the part after the period to determine which server that person should get sent back to.

I spent a large part of the day thinking the issue was an Apache configuration issue, as even with debug logging on, it wasn’t outputing anything. Once I looked through the code for mod_proxy_balancer, i saw that it ignores the cookie unless there’s a period in the string, and clearly there wasn’t one in my string.

After spending about 5 minutes trying to find a way to disable or change that behavior within ASP (there isn’t any as far as I can tell), I quickly found a solution within Apache!

Since Apache 2.2.4, the mod_headers module provides a method to edit a header using a regular expression. I was already using mod_headers to pass along some values through Apache (like the external IP address, or if the request was over HTTPS), so simply adding one line to the Apache configuration file fixed the issue:

Header edit Set-Cookie balancer%2Ewww balancer.www

Now, apache watches the response headers for when we are setting a cookie,  and if it contains “balancer%2Ewww” it gets rewritten as “balancer.www” and sure enough both Apache and IIS are perfectly happy with the cookie and everything is working well.

If I didn’t have access to the source code, it would have taken me weeks of trial and error to determine what the issue was or it would have been given up on for simply being incompatible. If apache wasn’t as flexible as it is, i would have been stuck writing a patch to mod_proxy_balancer and recompiling my own apache rather then relying on the distro’s packages for updates.

This is exactly where the closed source commercial software (Microsoft) and, to a much lessor-extent, the walled-garden open-source approach (like Django) run into issues. As long as you are only using that vendor’s software in the way that the vendor envisioned you would be using it, you’re just fine. Its also why standards are a good thing.

Yet another example of why Mark Ramm was right when he wrote and talked about WSGI being the right way to write tools that properly interact with one another. I’m really convinced now that the TurboGears/Pylons approach is the proper way to build web applications.