Issues with Finder as a WebDav client

Question

I have written a WebDav server that can be integrated into my iPhone app so as to allow some files to be transferred to and from the application. (I've already been through a long discussion as to whether or not Apple will allow this 'feature' but that is not the subject of this question).
When I use Finder as the client for my testing (both on the simulator and the device itself) I get the first part of the connection going and then Finder gives me an error that the server cannot be found on the network - even after it has already completed 2 request/response transfers with the server.
When I use CyberDuck as the client, it all works well and I can perform all of the interactions correctly.
I've used the 'PacketPeeper' application to look at the information passing between the client and the server and I can see no (significant) difference between the clients for the actual packets - its just that Finder simply stops sending sending packets except for one that has no payload and includes the 'FIN' flag.
The 'significant' word is used above because the XML data that is transferred back from my server to the client can either have all tags appended directly to the prior one, or can have line terminators and spacing added to the entire packet. Neither form makes any difference to CyberDuck or to Finder for the transfers that do occur. However when I monitor Finder talking to the 'AirShare' application, I see that AirShare formats some but not all of the XML - however the communication continues between Finder and AirShare. My understanding is that the formatting of the XML should make no difference to the information being passed.
Can anyone please tell me where I should be looking for a difference that is making my server fail with Finder?
I could simply carry on and blame a bug in Finder, but I really want the let Finder be a client as it will be available to all OS X-based users but other WebDav clients may not be.
Thanks
Susan

Answer 1

Found the problem and I'm describing it here in case it is of use to others.
The 'obvious' symptom was that Finder was sending the request for the 'OPTION" and 'PROPFIND' information and then displaying a popup dialog box saying that the server could not be found on the network.
The 'non-obvious' symptom was that there was an entry in the console log that the specified root was a file and not a directory, and giving the name of the file that the error was encountered (webdav_network.c) and the line number.
The problem turned out to be that when I was creating the XML response data header, I accidentally said "encoding=utf8" instead of "encoding=utf-8".
Looking at the code in webdav_network.c (which is part of the Darwin code set and therefore available on the Apple developer site) I found the place where the console log line was generated which was followed by a return status of 'no device' which must be interpreted by the rest of the finder as no server.
Tracing back a little further into the code (webdav_parse.c)I found where the XML was actually being parsed (using the core foundation event-driven XML parser functions) and noticed that there was no error checking code around the actual parse itself and so no error code was being returned. When I copied the appropriate parts of the code into my own program (so that I could debug it) I found that it was returning an error and the error was quite explicit: unrecognised encoding!
The parsing failure meant that the callback routines were not being called and so none of the flags and values were being set correctly. Because no error was being returned, back in the webdav-network.c file the parse was assumed to be successful and the incorrect parse state information was therefore being mis-interpreted (a check to make sure that the 'directory' flag had been set was failing which lead to the 'not a directory' console message).
If only the code had been written to do a bit more error checking and had returned more sensible error messages...!!!!!
Susan