Re: [Skunkdav-dev] content type
Status: Beta
Brought to you by:
smulloni
From: Torgeir V. <to...@ve...> - 2001-11-23 16:37:49
|
My views on content type follows. :) Jacob Smullyan wrote: > On Fri, Nov 23, 2001 at 05:10:36PM +0100, Torgeir Veimo wrote: > >>Jacob Smullyan wrote: >> >> >>>On Fri, Nov 23, 2001 at 04:00:36PM +0100, Torgeir Veimo wrote: >>> >>> >>>>When skunkdav saves a file, it automatically sets the content type to >>>>application/octet-stream, and not to the original content type of the >>>>document. >>>> >>>>Is this behaviour intended? >>>> >>>> >>>Not as such. SkunkDAV doesn't actually send a header like >>>"Content-Type: application/octet-stream" when it performs a PUT; but you are >>>right, it doesn't attempt to determine the mime type of the file and specify >>>it at PUT time. mod_dav/Apache makes this rather unnecessary, as it figures >>>out the mime type well enough on its own; what server are you using? >>> >> >>It is a server we are developing ourselves, but we used the catalina >>webdav servlet as a starting point. (See my comments on using >><D:propname> etc in another mail.) >> >> >> >>>Also, if you are not using the gui application, but just the library, you >>>can set the header yourself. >>> >>>The question remains, whether SkunkDAV should set the content-type; if the >>>specs point in that direction, let's add it. >>> >> >>If the document allready exist on the server, it probably has a content >>type as well. It would be nice if skunkdav remembered the content type >>it received when locking the file for editing. >> > > Hmm. If the document already, exists, should the server manage the content > type, or the client? > > Are you saying that SkunkDAV should read the server-maintained > getcontenttype property of the resource it is editing and mirror it back to > the server when it performs a put, but for a new resource it should > determine the content type by other means? Yes. this would be nice. > What should SkunkDAV do if it is > uploading a local file called "myprogram.txt" to a resource called > "myprogram.pl"? Then it should change it to text/plain. But if skunkdav downloaded a file from the webdav server with a content type of text/xml, even if the document was called myprogram.txt, it should not change the content type, unless the user specifically asked for it. Automatic content type detection should only come into action when dealing with a filesystem which cannot store content type explicitly. There are several sources of mime info here -- the > getcontenttype property, the local file's (guessed, whether on the basis of > file extension or magic number) mime type, the file extension of the remote > file. I wonder very much what is the sanest way for SkunkDAV to try to > balance those, and I also wonder whether that is really its responsibility. > I'll follow the specs, after investigation, but my gut feeling is that the > server should try to manage mime types as much as possible by itself, and if > they need to be user-modifiable, use a custom property that will give the > user control within server-defined limits over the live getcontenttype > property. We store the content in a database, thus do not detect based on file extension. When creatin a resource with no initial content we set it to text/xml. I think that setting the content type should be left to the client, but when it has been initially specified, the client shouldn't change it unless the user specifically asks it to do so. -- -Torgeir |