mnot’s blog

Design depends largely on constraints.” — Charles Eames

Wednesday, 15 May 2013

Indicating Problems in HTTP APIs

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...

this entry’s page (5 comments)

Sunday, 20 January 2013

A Short Note

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...

this entry’s page

Friday, 4 January 2013

Exploring Header Compression in HTTP/2.0

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...

this entry’s page (5 comments)

Tuesday, 18 December 2012

"Why Don't You Just…"

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...

this entry’s page

Friday, 7 December 2012

HTTP Status: 101 Switching Protocols

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...

this entry’s page (1 comment)

Creative Commons