spine.js: Does it really 'pipeline' POSTs?

Question

I was reading this post from Alex Maccaw, where he states :

The last issue is with Ajax requests that get sent out in parallel. If a user creates a record, and then immediately updates the same record, two Ajax requests will be sent out at the same time, a POST and a PUT. However, if the server processes the 'update' request before the 'create' one, it'll freak out. It has no idea what record needs updating, as the record hasn't been created yet.

The solution to this is to pipeline Ajax requests, transmitting them serially. Spine does this by default, queuing up POST, PUT and DELETE Ajax requests so they're sent one at a time. The next request sent only after the previous one has returned successfully.

But the HTTP spec Sec 8.1.2.2 Pipelining says:

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results.

So, does Spine really 'pipeline' POSTs ?

Answer 1

Maccaw's usage of the term "pipelineing" and that of the HTTP spec are not the same here. Actually, they're opposite.

In the HTTP spec, the term "pipelining" means sending multiple requests without waiting for a response. See section 8.1.2.2.

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response).

Based on this definition, you can see why the spec would strongly discourage pipelining non-idempotent requests, as one of the pipelined requests might change the state of the app, with unexpected results.

When Maccaw writes about spine's "pipelining", he's actually referring to the solution to the fact that the client will "pipeline" requests without waiting for a response, as per the HTTP spec. That is, spinejs will queue the requests and submit them serially, each consecutive request being made only after its predecessor completes.