3 ms·
You're mixing up safety with idempotency. What you call "idempotent communications" are only possible on a read-only server: if the state of a server can change
by Millennium 13y ago
You're mixing up safety with idempotency. What you call "idempotent communications" are only possible on a read-only server: if the state of a server can change, then the communications must change to reflect that. HTTP doesn't assume a read-only server: three of the common verbs (GET, PUT, and DELETE) are idempotent, but only one (GET) is safe.
- dpark 13y agoNo, I'm not. HTTP is a communications protocol. It doesn't dictate what a server should be doing internally, only how it should behave in the context of an HTTP session. If idempotency isn't important to the communications, why put it into the standard? For that matter, if idempotency is only relevant on the server side, then the server could do anything in response to a client request and it seems that the spec would be satisfied. void processRequest(httpcontext c) { // who cares?; this looks "idempotent" to everyone doSomethingArbitrary(); c.status = rand(); } RFC 2616 specifically discusses resuming in the face of dropped connections. This is only feasible if calls are idempotent from the client perspective (as well as the server perspective).