[Subversion Wiki] Update of "ServerDictatedConfiguration" by pburba

[Apache subversion Wiki <co...@subversion.apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "ServerDictatedConfiguration" page has been changed by pburba:
http://wiki.apache.org/subversion/ServerDictatedConfiguration?action=diff&rev1=26&rev2=27

Comment:
A few wording tweaks to reflect that the "server" dictated config proposed here is really per-repository, not per-server.

  ||ignores ||per-directory ||Enforceable via hook scripts || ||
  ||use-commit-times ||per-directory ||Unenforceable || ||
  ||log message templates ||per-directory ||Enforceable via hook scripts ||Doesn't fit the name=value configuration motif quite as readily as some of the others.  Would a client need to override this? ||
- ||store-plaintext-passwords ||per-server ||Unenforceable ||Should it be possible to override this without hacking the client? ||
+ ||store-plaintext-passwords ||per-repository ||Unenforceable ||Should it be possible to override this without hacking the client? ||
  
  
  
@@ -27, +27 @@

  The configuration the server dictates can at best be only a suggestion to the client. Older clients will obviously not even understand the new dictates.  As open source software, though, it is relatively easy for a malicious user to modify a client to ignore server-side suggestions.  Given this reality, server-side enforcement of desired behaviors (where possible, and often via hook scripts) is still strongly recommended.
  }}}
  === Server-client transmission mechanism ===
- When connecting to a server which supports this feature, the server will provide to the client a SHA1 checksum of its configuration.  A supporting client may then use that checksum (and the UUID of the repository) to compare against its own cached copy of the server configuration.  If the checksums differ, the client will request a new configuration from the server.
+ When connecting to a repository which supports this feature, the server will provide to the client a SHA1 checksum of the repository's configuration.  A supporting client may then use that checksum (and the UUID of the repository) to compare against its own cached copy of the repository configuration.  If the checksums differ, the client will request a new configuration from the server.
  
- Over ra-neon/ra-serf, the client will receive the server's configuration checksum as part of the OPTIONS response.  It will request new configuration bits via a custom REPORT request aimed at the repos-global report target (the "me resource" for HTTPv2, the "default VCC" otherwise).  ra-svn will behave similarly, using the initial handshake/feature negotiation phase for the server's checksum delivery, and a new query for the configuration fetch.
+ Over ra-neon/ra-serf, the client will receive the repository's configuration checksum as part of the OPTIONS response.  It will request new configuration bits via a custom REPORT request aimed at the repos-global report target (the "me resource" for HTTPv2, the "default VCC" otherwise).  ra-svn will behave similarly, using the initial handshake/feature negotiation phase for the repository's checksum delivery, and a new query for the configuration fetch.
  
  We plan to introduce a new capability string ("server-config") which clients should use to announce to the server that they will honor the server's dictated configuration.  Administrators may choose to use that string presence/absence in the list of capabilities passed to the start-commit hook to determine whether to allow commits from certain clients.