4 ms·
> QUERY requests are both safe and idempotent with regards to the resource identified by the request URI. Is that really what you want from a query operation?
by mjb 5y ago
> QUERY requests are both safe and idempotent with regards to the resource identified by the request URI.
Is that really what you want from a query operation? I read 'idempotent' as implying that result sets don't change over time, which would be surprising behavior for queries for most database-like things.
It's probably also worth mentioning that SQL's SELECT isn't idempotent in the way HTTP means it, because of the existence of session state, pessimistic locking, and the requirements of higher isolation levels. It would be useful for an RFC to define 'idempotent' in a way that clearly addressed these issues (and, for that matter, the larger topic of sessions/transactions) more clearly.
> When doing so, caches SHOULD first normalize request content to remove semantically insignificant differences, thereby improving cache efficiency
Unfortunately, again when you look at SQL by comparison, queries are not purely expressions of what to return. Practically, they also encode how to compute the query (either explicitly through hints, or implicitly through things like join order). These behaviors are weird, tricky, and change version-to-version.
> The QUERY method is subject to the same general security considerations as all HTTP methods as described in
As another commenter said, this is quite incomplete. Query parameter injection, DoS by locking, DoS by exploiting work the database needs to do to ensure isolation, DoS by extremely expensive query, etc.
> 4.2. Simple QUERY with indirect response (303 See Other)
At least the examples here are naive - most applications don't want query result sets to be easily accessible to others. The semantics of authn and authz need to be really crisp here to make sure that attackers can't access the location of other queries result sets purely by guessing.
At least a "SHOULD use auth" or "SHOULD have large, unguessable, names" would be valuable here.
- detaro 5y ago> I read 'idempotent' as implying that result sets don't change over time, which would be surprising behavior for queries for most database-like things. That's not what idempotent means in HTTP. > As another commenter said, this is quite incomplete. Query parameter injection, DoS by locking, DoS by exploiting work the database needs to do to ensure isolation, DoS by extremely expensive query, etc. Is application-dependent and applies to all other HTTP methods too.
- mjb 5y agoRFC2616 says: > A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by reexecution of all, or part, of that sequence. Which isn't, because of isolation, true in general of database queries. Obviously this is in context of RFC2616 saying that sequences of idempotent HTTP operations may not be idempotent in themselves, but that definition seems very incomplete in the context of database queries. > Is application-dependent and applies to all other HTTP methods too. Sure. But I don't think that's a good argument in the modern world. Over the 22 years, we've learned a lot about the security concerns of running secure systems, and it seems reasonable to include those concerns in a section labelled "security considerations". SQL injection is a classic security bug, and should be a key concern of any reasonable new standard for sending queries between systems. A full security section should probably also mention cache timing side-channels, locking-related covert channels, and other similar concerns that come up when you increase the semantic power of HTTP. It's not that POST doesn't have these concerns, it's that we've learned in the last two decades that they are real problems for many kinds of real systems.
- detaro 5y agoHTTP idempotence is only concerned with effects of the request, not the result returned. RFC7231: > A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. note the on the server. (or old specs, 2616: Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. - again, side-effects, not responses) How does a read-only database query being repeated cause a change in the database?
- timwis 5y agoIdempotency in the HTTP context is about the ability to make the same request multiple times without side effects. https://developer.mozilla.org/en-US/docs/Glossary/Idempotent https://developer.mozilla.org/en-US/docs/Glossary/Idempotent
- zinekeller 5y agoa) GET is also idempotent despite the fact that a re-request may retrieve a updated document. b) Some developers are ignoring HTTP idempotency. Not IETF's fault for them abusing GET for deletion.
- marcosdumay 5y agoWell, GET is not idempotent if the document has been updated. The specs do not talk much about the document changing behind your back, only about the changes you cause by yourself.
- timwis 5y agoBut if you GET /posts/123 and then do it again, and in between, the author updated the post, you’d expect to get the latest version of the post, no? That doesn’t make it non-idempotent, because your GET requests did not change the state at all.
- user3939382 5y agoMaybe the distinction is that the request (your request) is itself not responsible for the change.
- brainwipe 5y agoThis is correct. Idempotent GET should not itself change the state of the server.
- atuladhar 5y agoI'm pretty sure timwis and zinekeller in this thread (and detaro in the sibling thread) are all saying the same thing. Idempotency implies the request in question does not change the state, not that the state would not have changed because of other operations in the meantime. GET and QUERY are meant to be idempotent but whether they really are in practice depends on how they've been implemented.
- himinlomax 5y ago> I read 'idempotent' as implying that result sets don't change over time Idempotent means the request itself doesn't change stuff, it doesn't mean something else won't.
- mjb 5y agoYou're right, and I was fuzzy about what I meant. I didn't mean (although wasn't clear) that QUERY would have to return the whole result set over time - clearly that's beyond the scope of HTTP's definition of idempotency. However, because of the existence of isolation and locking concerns in databases, even fairly simple queries are not idempotent. RFC2616 goes to some effort to (fuzzily, unfortunately) talk about sequences of operations, which would be useful here.