Wednesday, 15 May 2013
A common part of HTTP-based APIs is telling the client that something has gone wrong. Most APIs do this in some fashion, whether they call it a “Fault” (very SOAP-y), “Error” or whatever. Most of them define a new format for just this purpose; for examples, see Amazon’s, OpenStack’s, Twitter’s, Facebook’s, and SalesForce’s. Twitter's is fairly representative: {"errors":[{"message":"Sorry, that page does not exist","code":34}]} Here, they associate a human-readable message and an error code with the error. That’s a good start, but...
Sunday, 20 January 2013
In 2001, Charlie was born, and (understandably) we were freaking out a bit, having a new child and all. However, at about the same time, I met this really remarkable kid at the W3C, and I asked him what advice he could give me, from his perspective. The response was that school was rubbish ;) and a recommendation for a book (which I still have, somewhere). Over the years, we e-mailed a bit, especially about RSS and some Web-related software...
Friday, 4 January 2013
One of the major mechanisms proposed by SPDY for use in HTTP/2.0 is header compression. This is motivated by a number of things, but heavy in the mix is the combination of having more and more requests in a page, and the increasing use of mobile, where every packet is, well, precious. Compressing headers (separately from message bodies) both reduces the overhead of additional requests and of introducing new headers. To illustrate this, Patrick put together a synthetic test that...
Tuesday, 18 December 2012
A proposal by John Graham-Cumming is currently doing the rounds: HMURR (pronounced ‘hammer’) introduces a new pipelining mechanism with explicit identifiers used to match requests and responses sent on the same TCP connection so that out-of-order responses are possible. The current HTTP 1.1 pipelining mechanism requires that responses be returned in the same order as requests are made (FIFO) which itself introduces a head-of-line blocking problem. This seems attractive at first glance; rather than starting a whole new protocol, why not just incrementally improve an...
Friday, 7 December 2012
The HTTPbis Working Group met in Atlanta last month; here’s how things are going. HTTP/1.1 We’re now out of Working Group Last Call on all of our “core” documents, so the editors are working through the issues that brought up. As soon as that’s done, we’ll go to IETF Last Call, and hopefully soon after well have a number of new RFCs defining HTTP/1.1. Here, you can see the upswing in number of issues during our WGLC period: To see...
