Re: [Skunkdav-dev] content type

[Jacob S. <smu...@sm...>]

OK; sounds fine.  Provided that specifying content type won't have any weird
consequences with mod_dav, I'll make that change.

The xml namespace problem is the one for which I put in a (possibly
ineffective) fix;  I'll perform some tests and get back to you.


On Fri, Nov 23, 2001 at 05:36:52PM +0100, Torgeir Veimo wrote:
> 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
> 
> 
> _______________________________________________
> Skunkdav-dev mailing list
> Sku...@li...
> https://lists.sourceforge.net/lists/listinfo/skunkdav-dev

-- 
Jacob Smullyan | smu...@sm...
http://www.smullyan.org/smulloni/