We tried to do this at Orbital Data (WAN optimization firm), and one or more existing TCP implmentations didn't support it. Compatibility with existing implementations was a significant barrier to optimizations that were technically permitted within the spec.
I dont recall exactly which TCPs this broke, but I do remember the implementations for VXWorks, some thirdparty TCP for mainframe OSs (IBM 370), and Solaris were often the culprit, and less often there was a problem with a Windows TCP (remember there are different releases to test of each. If you don't, your customers will). While I realize you may not care about those servers, you really don't want to make changes to the client that are incompatible.
I'd suggest checking with the SPDY guys. They've done tons of testing of various latency improvements.
Seems like it's likely to be very difficult for a browser to detect whether or not a given request is idempotent, no? You could use HTTP verbs (i.e. assume that GETs are and POSTs are not) but then you're trusting the server to use REST correctly.
I had the same sort of thought: it's really, really difficult for the bulk of programmers to create an idempotent operation. Therefore, through no fault of its own, TCP Fast Open would acquire a reputation for goofy behavior.
I dont recall exactly which TCPs this broke, but I do remember the implementations for VXWorks, some thirdparty TCP for mainframe OSs (IBM 370), and Solaris were often the culprit, and less often there was a problem with a Windows TCP (remember there are different releases to test of each. If you don't, your customers will). While I realize you may not care about those servers, you really don't want to make changes to the client that are incompatible.
I'd suggest checking with the SPDY guys. They've done tons of testing of various latency improvements.