TCP Fast Open: expediting web services [LWN.net]

TCP Fast Open: expediting web services

Posted Aug 2, 2012 13:16 UTC (Thu) by epa (subscriber, #39769)
In reply to: TCP Fast Open: expediting web services by colo
Parent article: TCP Fast Open: expediting web services

Long ago I worked at ArsDigita where the rule was to avoid form submit buttons as much as possible. So the user management page on a site would have 'delete user' not as a POST form submission, but simply a hyperlink. This was held to make the website look cleaner and feel faster. Then a customer using a 'web accelerator' which eagerly follows links ended up trashing their whole site. The programmer's fault, of course - GET requests should never be used for strongly state-changing operations like deleting data.

to post comments

TCP Fast Open: expediting web services

Posted Aug 2, 2012 14:04 UTC (Thu) by alankila (guest, #47141) [Link] (7 responses)

Although to be fair, multiple GETs that all attempt to delete the same user aren't a problem here. So maybe the latter request crashes if website developer wasn't careful enough, but the delete itself was idempotent.

I guess cautious people can't turn TFO on unless they validate the software they runs, but now there is going to be a good reason why you want to ensure that software is idempotent-GET safe. I imagine that the vast majority of software is, actually.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 15:19 UTC (Thu) by epa (subscriber, #39769) [Link] (6 responses)

Yes, I was confusing idempotent (makes no difference whether requested once, or many times) with stateless (makes no difference whether requested zero, one, or many times). Ideally GET requests would be not merely idempotent but stateless, which is a stronger property. But that is not needed for TFO.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 16:11 UTC (Thu) by man_ls (guest, #15091) [Link] (5 responses)

That is not required in the RFC, and I am not sure that restful, stateless web services would be even possible. After all, web services are supposed to change state in the server; otherwise what is the point?

TCP Fast Open: expediting web services

Posted Aug 2, 2012 16:32 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (4 responses)

Maybe I don't understand. Internally we have a great many RESTful web services which all work roughly like this:

The client asks if this particular combination of data (provided as GET query parameters) is found in the database overseen by that web service. The server looks in its database (e.g. maybe it's the collection of all voter registration records for a particular country) and if there is a matching record it replies saying what was found and where.

You can run that same request again and get the same exact answer and running it many times or not at all changes nothing‡ so that seems to meet your requirement entirely.

‡ In practice some of the services do accounting, they are incrementing a counter somewhere for every query run and then we use that counter to determine the payment to a third party for the use of their data. But this is no greater deviation from the concept than the usual practice of logging GET requests and anyway most of the services don't do that.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 20:42 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

you are making the assumption that the RESTful web service is read-only.

How can you do a RESTful web service where the client is sending information to the server without causing these sorts of problems?

TCP Fast Open: expediting web services

Posted Aug 3, 2012 2:02 UTC (Fri) by butlerm (subscriber, #13312) [Link]

The normal technique is to mark all non-idempotent requests with a unique id, and keep track of which ones have already been processed. That is practically the only way to get once-only execution semantics.

This could presumably be done (up to a point) at the transport layer with TCP Fast Open by having the initiating endpoint assign a unique identifier to a given user space connection request, attaching the identifier as a TCP option, caching the identifier for some reasonable period on the target endpoint, and throwing away SYN packets with connection identifiers that have already been satisfied. The more general way to do that of course is to do it at the application layer, in addition to anything the transport layer may or may not do.

TCP Fast Open: expediting web services

Posted Aug 3, 2012 15:35 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

I thought that part of making a RESTful web service was deciding which operations are read-only and which affect the state; and splitting them into GET and POST requests accordingly.

TCP Fast Open: expediting web services

Posted Aug 3, 2012 21:16 UTC (Fri) by dlang (guest, #313) [Link]

That depends on how you define REST

many groups make everything a GET request, especially for APIs that are not expected to be used from browsers, but rather called from other applications, especially in B2B type situations.