As a result we don't need to keep the initial databases in Git, or
in the release, and we have a way of running all regression tests
as well as just running small subsets when we need to.
When the WebDAV sync draft first came out the responses were each
contained in a DAV::sync-response tag, but by -03 this has changed
to a DAV::response tag since the format of the tag contents now
match this existing tag structure.
Unfortunately some client software in the wild depends on this
being a DAV::sync-response so the config option is needed to
interoperate with this software.
It seems that on PUT Google might truncate the filename, so it will
send us back a Location header we need to follow before we can
getr the ETag. And there might be one more hoop to jump through
to complete this process.
This would be better handled if we locally use the VEVENT UID as
the invariant property between local and remote, rather than the
'filename' part of the path, but we'd still face the issue of
having to follow the Location: header to get the ETag for the
event we just PUT to the remote server.
PAM authentication uses a regular expression to extract the user's real
name from the 'user name or comment field' passwd file when creating a
new account.
The current regular expression assumes the comment field contains the
user name followed by a comma and some other comma-delimited information
(the Linux 'adduser' command adds room number, work phone, home phone
and 'other' info given half a chance).
If the field just contains the user name, there is no trailing comma
and the RE match fails. Make the trailing comma optional.
Signed-off-by: Andrew McMillan <andrew@morphoss.com>
We do a HEAD if we didn't get the ETag back from the PUT, but the server
at the other end may have sent us a new location for the resource and
we'll need to handle that at a higher level, so we make sure to preserve
the original response from the PUT.
