0

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 ?

2020
  • 2,821
  • 2
  • 23
  • 40

1 Answers1

3

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.

numbers1311407
  • 33,686
  • 9
  • 90
  • 92
  • So, spinejs achieves the same effect as what we will get if "HTTP Pipelining" were to be disabled ? If yes, couldnt we just disable "HTTP pipelining", rather than enable it and then disable it using spinejs ? (I dont know if we can programmatically disable "HTTP Pipelining", though). – 2020 Apr 30 '13 at 00:37
  • 1
    You might say that, yes. As he says, it queues the requests and only executes each after the previous one completes, meaning spine only makes one put/post/delete at a time. HTTP Pipelining is a function of the browser, even if you could turn it off (you could probably limit concurrent requests in firefox, for example), you can't make users do this. And moreover spinejs uses it's "pipeline" as a control mechanism, or so it seems by the description, only making the next request if the previous one succeeds. – numbers1311407 Apr 30 '13 at 00:39
  • 1
    Plus, I'm sure spine "pipelines" GET requests, and more importantly, you ***probably*** don't want your web app only requesting one file at a time from your server. – numbers1311407 Apr 30 '13 at 00:43
  • Definitely agree with you on that ! – 2020 Apr 30 '13 at 00:45
  • You mentioned "spinejs will queue the requests and submit them serially, each consecutive request being made only after its predecessor completes". But that seems so wrong ! Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ? What if the POSTS are on related URIs ? Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ? – 2020 Apr 30 '13 at 17:12
  • 1
    That's a good question. I really don't know. I was just quoting what MacCaw said in the quote you posted in the original question. From his explanation, I would assume this only really matters for (what would otherwise be) parallel requests from the same client. If a client sends a lone PUT for a resource that doesn't exist, it should probably get a 404 and deal with it, but if a client sends a CREATE and a PUT in parallel and the PUT gets there first, and fails, then that's a problem. But like I said, I really don't know. My answer was just to clarify his meaning of "pipelining" :-P – numbers1311407 Apr 30 '13 at 17:20
  • Completely agree that your response completely addressed my original question. I dont know if I should create a new question for this "thing" that has come up as a result of our discussion. Am assuming it is ok to edit the original question with this. Thanks ! – 2020 Apr 30 '13 at 17:24