https://issues.apache.org/bugzilla/show_bug.cgi?id=55420
Bug ID: 55420
Summary: Integer underflow in lock timeout computation
Product: Apache httpd-2
Version: 2.4.4
Hardware: Macintosh
Status: NEW
Severity: normal
Priority: P2
Component: mod_dav_lock
Assignee: [email protected]
Reporter: [email protected]
Issuing a LOCK command returns an XML response describing the acquired lock,
including its timeout.
If the request is issued on a resource which takes a while to lock (e.g.,
because it's a large collection, or the disk is under heavy load) then the
returned timeout is smaller than the request by the amount of time the LOCK
request took to execute (this seems ok to me).
If the request takes so long that the lock has timed out before it is
completely acquired, then Apache will expire the lock, but will return a large
positive timeout to the client (for example, "Second-18446744073709551612" for
a 30-second lock which took 34 seconds to acquire). This is obviously
incorrect.
Any of the following behaviors would be more correct than the current behavior:
- Fail the request with 408 REQUEST TIMEOUT.
- Return a timeout of "Second-0" which clients would plausibly interpret to
mean that the lock was acquired but is already gone.
- Adjust the timeout of the lock upwards so that the returned timeout is
positive (RFC4918 allows this).
(Note that the returned value also violates RFC4918 section 10.7 because it is
greater than 2^32, but that is less important, imho.)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
