All posts tagged ‘HTTP’

File Under: Web Standards

Error 451: This Page Has Been Burned

Earlier this month Google developer advocate Tim Bray proposed a new HTTP Error status code aimed at shining a light on web censorship.

Bray’s new Error 451 would work somewhat like the Error 404 pages you’ve probably seen. But instead of telling you that the page could not be found, an Error 451 response would let you know that the page you were looking for had been censored.

The number is a tribute to author Ray Bradbury (commenters on a Slashdot thread independently suggested 451 as well).

As it stands, most web-blocking tools return a 403 error (which means access is forbidden) when denying access to censored pages. For instance, UK ISPs, which are now required to block The Pirate Bay, typically return a 403 error code when doing so.

The main advantage of the proposed 451 code is that it would add an explanation of why the content was unavailable. “Responses using this status code should include an explanation, in the response body, of the details of the legal restriction,” writes Bray in his proposal. Details would include tidbits like which legal authority is imposing the restriction, and what class of resources it applies to.

That would mean ISPs could return a message absolving themselves and letting citizens know that the government, not the ISP, is censoring the web.

Bray notes in the proposal that many governments might not want such censorship transparency and would likely take steps to prevent it. As such the 451 status code would be optional and clients (like your web browser) are instructed not to rely upon its use. It also remains to be seen whether the Internet Engineering Task Force, which oversees standards like HTTP error codes, will approve of the idea.

File Under: Backend, servers, Web Basics

Move Over, HTTP. Say ‘Hello World’ to SPDY

Google plans to introduce a new protocol for web transactions it says is more than 50 percent faster than HTTP.

A post on Google’s Chromium blog describes the new protocol, SPDY, pronounced “Speedy”:

SPDY is at its core an application-layer protocol for transporting content over the web. It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression.

The Chromium team, which is in charge of developing the Chrome browser and its associated technologies, reports that SPDY has been able to load web pages 55 percent faster than the HTTP protocol in lab conditions using simulated home-network connections. The team says its goal is to make SPDY eventually run twice as fast as HTTP.

HTTP is the language currently used by servers and browsers for the vast majority of common tasks on the web. When you request a web page or a file from a server, chances are your browser sends that request using HTTP. The server answers using HTTP, too. This is why “http” appears at the beginning of most web addresses.

So, Google’s proposal would involve rewriting the web’s most commonly used and baked-in transaction method.

“HTTP has served the web incredibly well,” the post’s authors write. “We want to continue building on the web’s tradition of experimentation and optimization, to further support the evolution of websites and browsers.”

If such a massive shift were to ever take place (and nobody’s promising it will at this point), it would require a whole lot of buy-in from outside Google. To that end, the company is releasing its early-stage documentation and code for SPDY along with a call for feedback.

It may seem like a brash move, but the Chromium team seems to enjoy ruffling feathers. In September, the same group released the Chrome Frame plug-in for Internet Explorer which essentially embeds Google’s browser inside Microsoft’s, giving the ability to render websites that IE wouldn’t normally be able to handle.

To contribute to the SPDY discussion, visit the Chromium Google Group.

Image: Warner Brothers

See Also: