This is a problem specific to Launchpad bugs. The problem does not exist in the lazr.restful example web service, and it doesn't exist for other Launchpad resources (such as people). Everyone who's commented on this thread has had a problem with bugs.
The culprit is the date_last_updated field. Here are the only differences between the version of the bug received along with a 209, and the same bug retrieved an instant later with a fresh GET request.
date_last_updated: 2006-07-14T08:54:19.453881+00:00 became 2009-04-23T15:03:50.557586+00:00
http_etag: "490b68f89bc09bc705018ee8066eb985261e55bd" became "fcbc53f773fe21b99154c7fd41c04facbf415477"
date_last_updated is updated after the ETag is calculated, possibly in response to the ObjectModifiedEvent. Or maybe it's done by a database trigger. I'm not sure. Anyway, the bug gets changed twice, and the effect is the same as if someone else modified the bug after you did: your copy of the bug is no longer valid.
This is a problem specific to Launchpad bugs. The problem does not exist in the lazr.restful example web service, and it doesn't exist for other Launchpad resources (such as people). Everyone who's commented on this thread has had a problem with bugs.
The culprit is the date_last_updated field. Here are the only differences between the version of the bug received along with a 209, and the same bug retrieved an instant later with a fresh GET request.
date_last_updated: 2006-07- 14T08:54: 19.453881+ 00:00 became 2009-04- 23T15:03: 50.557586+ 00:00 c705018ee8066eb 985261e55bd" became "fcbc53f773fe21 b99154c7fd41c04 facbf415477"
http_etag: "490b68f89bc09b
date_last_updated is updated after the ETag is calculated, possibly in response to the ObjectModifiedE vent. Or maybe it's done by a database trigger. I'm not sure. Anyway, the bug gets changed twice, and the effect is the same as if someone else modified the bug after you did: your copy of the bug is no longer valid.