According to http://www.webdav.org/specs/rfc4918.html#HEADER_DAV, a
server may extend the DAV: headers with arbitrary values, for instance
to indicate server capabilities. Indeed, mod_dav has done so before,
thus Neon has this code in ne_basic.c:parse_dav_header():
do {
char *tok = ne_qtoken(&pnt, ',', "\"'");
if (!tok) break;
tok = ne_shave(tok, " \r\t\n");
if (strcmp(tok, "1") == 0) {
caps->dav_class1 = 1;
} else if (strcmp(tok, "2") == 0) {
caps->dav_class2 = 1;
} else if (strcmp(tok, "<http://apache.org/dav/propset/fs/1>") == 0) {
caps->dav_executable = 1;
}
} while (pnt != NULL);
Unfortunately, ne_options(), the caller of the above code, has no way
to return whatever arbitrary values the server sends back in the
headers. Neon has no way to even *represent* such values, since the
'ne_server_capabilities' struct is just three ints:
/* Server capabilities: */
typedef struct {
unsigned int dav_class1; /* True if Class 1 WebDAV server */
unsigned int dav_class2; /* True if Class 2 WebDAV server */
unsigned int dav_executable; /* True if supports the 'executable'
* property a. la. mod_dav */
} ne_server_capabilities;
Hence the lack of a final 'else' clause in parse_dav_header() --
there's nothing Neon could do with values it doesn't recognize anyway,
so it tosses them.
Is this a bug, given the spec's allowance for arbitrary extensions?
It seems that the three capabilities currently defined in the struct
are all WebDAV-specific already, and the last of them clearly
postdates the spec.
In the meantime, suggestions on how to parse some new header values
out are very welcome :-). I'm adding some for a new Subversion
feature see http://subversion.tigris.org/issues/show_bug.cgi?id=2959
and http://pastebin.ca/732260 for context.
-Karl Fogel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 10 22:24:42 2007