Comment by mjb | Hacker News Reader

Comment by mjb | Hacker News Reader

> 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.

Idempotency 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

a) 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.

But 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.

Maybe the distinction is that the request (your request) is itself not responsible for the change.

This is correct. Idempotent GET should not itself change the state of the server.

I'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.

Idempotency only refers to state changes from subsequent invocations of the call.

A command to add a user to the set of users that have upvoted a post would be idempotent. Because you can run it 20x and only the first call affects anything. A command to increase the upvote count for a comment by +1 would not be idempotent.

Good point!

> But 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?

Not necessarily - plenty of systems offer no such guarantees, and the Web is by design eventually consistent [0]. This is what content expiration and various other cache control mechanisms are for - it's not always so important to get the latest version of a document. For example, the HN logo or index.html can probably be safely cached for days, since they are very unlikely to change, and even if they do, it's unlikely to have a major problem if someone only sees the new version after a few days.

[0] Note that, at the extreme, due to special relativity, there is no absolute notion of "latest version" on the scale of geographically distributed computers: it's physically impossible to say if a request made in China to a server in the USA happened before or after a change on the server, if they happened close enough together - order of tens of milliseconds, an eternity in compute time.

Well, 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.

But idempotency is relevant because of two things:

1) is it safe to automatically retry the request? - this meshes well with what you're saying

2) is it safe to return a cached version of the response, instead of sending the request again? Idempotence in your sense is necessary but not sufficient for this case - hence the various content expiration and If-Newer-Then etc headers.

> 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.

RFC2616 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.

HTTP 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?

> 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.

You'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.

Reply on news.ycombinator.com