Kent, Balazs,
I don’t see a specific need for timestamps, so I can accept your arguments
against it. Just add a sentence about it somewhere into the draft. It can be an
appendix.
OK with me.
A timestamp could be added in the future if it is really important enough.
LastModified is drop-dead simple to do and achieves equivalency, no more
justification is needed.
The same rules apply:
- ETag is a MUST, LastModified is a MAY
- root-node is a MUST, inner-nodes is a MAY
I'm perfectly fine with this. Since we are in agreement maybe I should just
stop here.
Since I noted that I haven't done a good job at explaining how the ETag
mechanism works, let me take the example below and explain how this situation
is avoided using ETags.
I also realized that servers supporting Last-Modified in deeper levels than
just the root can do the same thing as I explain for ETags below.
f this isn't obvious, here's an example:
1. Client A sends an edit to the server If-Unmodified-Since t0. Successful.
Receives a Last-Modified timestamp t1.
2. Client B sends a an edit to the server. Last-Modified timestamp on server is
now t2.
3. Client A sends an edit to the server without If-Unmodified-Since. It just
sets one tiny little leaf off in one corner. Successful. Received a
Last-Modified timestamp t3.
4. Client A sends an edit to the server If-Unmodified-Since t3. Successful, but
clobbers Client B's edit, leading to a misconfiguration, which opens a security
hole.
This is because the If-Unmodified-Since uses less than or equal in its test.
The ETag mechanism is not susceptible to this issue, as it uses an equality
test.
I don't think this example is valid. Skipping past the obvious programming
error, the equivalency you're trying to make applies to Etags too.
1. Client A sends an edit to the server If-Match e0. Successful. Receives a
ETag e1.
2. Client B sends a an edit to the server. ETag on server is now e2.
3. Client A sends an edit to the server without If-Match. It just sets one tiny
little leaf off in one corner. Successful. Received a ETag e3.
4. Client A sends an edit to the server If-Match e3. Successful, but clobbers
Client B's edit, leading to a misconfiguration, which opens a security hole.
Here's the same example again in some greater detail.
1. Client A edits server:/{eQ}ifs/{eR}interface[name="1/1/1"]{eZ}/... where
{eX} means that the client asks the server to confirm the ETag value X sits at
the path to the left before committing. Success. Server returns new ETag eB on
/ (the root), /ifs and interface 1/1/1.
2. Client B edits server:/acls[name="intf 1/1/1"]/... and server sets ETag eF
on / and /acl intf 1/1/1.
3. Client A edits server:/users/user[name="joe"]/password without any ETag
check. Server sets eY on / and /users.
4. Client A edits server:/{eY}acls[name="intf 1/1/1"]{eB}/... . Check eB fails
(server has eF), edit aborted.
Best Regards,
/Jan
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
