The [[Stateless server|stateless]] nature of [[HTTP]] makes locking infeasible for web user interfaces. It's is common for a user to start editing a record, then leave without following a "cancel" or "logout" link. If locking is used, other users who attempt to edit the same record must wait until the first user's lock times out.
[[HTTP]] does provide a form of built-in OCC:. The response to an initial GET methodrequest returnscan include an [[HTTP ETag|ETag]] for asubsequent resourcePUT andrequests subsequent PUTsto use the ETag value in the If-Match headers;header. while the firstAny PUT willrequests succeed,with thean secondout-of-date willETag not, asin the value in If-Match isheader basedcan onthen the first version of thebe resourcerejected.<ref>{{cite web | url = http://www.w3.org/1999/04/Editing/ | title = Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout | work = W3C Note | date = 10 May 1999}}</ref>
Some database management systems offer OCC natively -, without requiring special application code. For others, the application can implement an OCC layer outside of the database, and avoid waiting or silently overwriting records. In such cases, the [[Form (web)|form]] includesmay include a hidden field with the record's original content, a timestamp, a sequence number, or an opaque token. On submit, this is compared against the database. If it differs, the conflict resolution algorithm is invoked.
