> "Daniel Patterson" <email@example.com> writes:
>> How important is the accuracy of the log? If the client is supplying
>> the critical information, it's vulnerable to tinkering, maliciously
>> or otherwise. How much of a headache will it be if a non-official
>> client sends an 'operation_name' with a typo?
> No trouble at all, as long as the server admins are aware of this.
> Remember that the server cannot be fooled about what the client
> actually did -- the low-level requests cannot be disguised. The
> client can claim an inaccurate overall name for the operation(s)
> comprised by these low-level requests, or fail to supply a name at
> all, or claim it wanted something it didn't really want, but that's
> it. The client cannot actually fool the server into not knowing what
> work it (the server) did.
> All this is true for CVS 'history' as well: the client could falsely
> claim to have "released" a working copy, for example.
> I feel like a common misunderstanding is going to keep coming up in
> this thread, and I want to head it off right now:
> For judging server *workload*, we don't need any protocol additions.
> The server already knows what it does, and it could log these things
> (mod_dav_svn already does so in the Apache HTTPD logs, in fact). But
> that's a different feature, and is not addressed by this patch. This
> patch is about logging the conceptual operations the client intended
> to perform (commit, update, merge, diff, blame, etc).
But since it is prone to tinkering (you can hack up your client to
say 'banana' instead of 'commit' or something worse), this data can
only possibly be used for statistics.
I wonder if the conceptual operations are that important. For auditing
purposes you are more interested in which 'paths' a user has read from
or written to (the latter is not strictly available in the version
history since the write may have occurred in an aborted txn).
Note that, in case of mod_dav_svn, with REPORT requests you don't see
all the paths themselves in the access.log, so there is no hint what
was really read.
I realise I haven't been following the entire discussion, so I hope
this wasn't already hashed over before... :/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jun 7 19:21:09 2005