On Fri, Sep 22, 2017 at 4:40 AM, Richard Barnes <r...@ipv.sx> wrote: > Daniel noted that there might be some issues with GET idempotency here, but > I don't think this actually makes GET non-idempotent.
It's still idempotent, because doing the GET twice has the same effect as doing it once. You are concerned about the GET no longer being safe. That is, it is no longer side-effect free. It is OK to do things in response to a GET as long as the server owns the consequences. Servers frequently log GET requests, which isn't safe or even idempotent, but servers do it because there is an advantage to them that exceeds the costs. As long as clients aren't held accountable for these side-effects, it's OK. Or, you could consider the resource to have been updated at some point in the past as though the authorization triggered proactive issuance, but it's just that the GET has taken a little while to "find" the updated state. Think of it as a lazy load, or maybe an extreme case of the server cache needing to be populated. If you like, we could also dive into whether this specific type of request is safe to send in 0-RTT, but I don't have the brain cells for that right now. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
