You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Martin Gronberg <ma...@everest.com> on 2001/04/26 00:57:07 UTC

Re: WebDAV PUT Problem

Seems like there is a bug in PutMethod related to this.

Turns out this is related to LOCK before PUT.  MS Word calls LOCK before 
it calls PUT.  LockMethod will create a NodeRevisionDescriptor for the 
lock.  When the PutMethod is called, it should normally throw an 
ObjectNotFoundException when content.retrieve( ) is called and the catch 
clause will fill in the contentType.

Because that lock descriptor is there, content.retrieve( ) gets it and 
updates it to represent the new file.  The try block does not set 
'getcontenttype' or 'getcontentlanguage' when updating an old descriptor 
or even when creating a new one.

Seems like the PutMethod needs to be a little more discriminating when 
retrieving an oldRevisionDescriptor and, in the case where a new one is 
created, needs to add the 'getcontenttype' and 'getcontentlanguage' 
properties.

What do you think?

   Marty

Martin Gronberg wrote:

> Env: Slide 1.0.9, Tomcat 3.2.1, Linux RedHat 6.2
> 
> Problem: When saving a MSWord document from MSWord | Save As... the 
> file is stored without the 'getcontenttype' and 'getcontentlanguage' 
> properties.
> 
> When I save a file using the MSWin2K File Explorer all the properties 
> are created and saved including the 'getcontenttype' and 
> 'getcontentlanguage' but not when I save using MSWord.  I was looking 
> at the code and it seems like the PutMethod.executeRequest( ) should 
> always add these properties to the revisionDescriptor for new 
> objects.  Any ideas as to what could be going on?
> 
>   Marty



Re: Proposed Patch [Re: WebDAV PUT Problem]

Posted by Remy Maucherat <re...@apache.org>.
> I basically added code to conditionally check for the lock problem.  
> Without this, the getcontenttype won't be set in the case where a 'lock' 
> is done before the 'put' and then the client can't determine the content 
> type and opens the document with the wrong application.

Checking for lock-null explicitely is probably the best solution.
Thanks for the patch !

Remy


Proposed Patch [Re: WebDAV PUT Problem]

Posted by Martin Gronberg <ma...@everest.com>.
I basically added code to conditionally check for the lock problem.  
Without this, the getcontenttype won't be set in the case where a 'lock' 
is done before the 'put' and then the client can't determine the content 
type and opens the document with the wrong application.

   Marty

$ diff -Naur 1.8/PutMethod.java new/PutMethod.java
--- 1.8/PutMethod.java    Tue Apr 24 11:42:31 2001
+++ new/PutMethod.java    Thu Apr 26 09:16:59 2001
@@ -190,6 +190,26 @@
                property = new NodeProperty("getetag", etag, true);
                revisionDescriptor.setProperty(property);
               
+        // Normally assume the 'getcontentlanguage' and
+        // 'getcontenttype' are set, however, before we clear the
+        // 'resourcetype' need to check for the case when a
+        // 'lock-null' is created just before the initial PUT. In
+        // that case need to add the missing properties.
+        property = revisionDescriptor.getProperty("resourcetype");
+        if (((String)property.getValue()).equals("<lock-null/>")) {
+            property = new NodeProperty("getcontentlanguage", "en", true);
+            revisionDescriptor.setProperty(property);
+
+            String contentType =
+            servlet.getServletContext().getMimeType(resourcePath);
+            if (contentType == null) {
+            contentType = "TEXT/PLAIN";
+            }
+            property = new NodeProperty("getcontenttype", contentType,
+                        true);
+            revisionDescriptor.setProperty(property);
+        }
+       
                // Resource type
                property = new NodeProperty("resourcetype", "", true);
                revisionDescriptor.setProperty(property);

Martin Gronberg wrote:

> Seems like there is a bug in PutMethod related to this.
> 
> Turns out this is related to LOCK before PUT.  MS Word calls LOCK 
> before it calls PUT.  LockMethod will create a NodeRevisionDescriptor 
> for the lock.  When the PutMethod is called, it should normally throw 
> an ObjectNotFoundException when content.retrieve( ) is called and the 
> catch clause will fill in the contentType.
> 
> Because that lock descriptor is there, content.retrieve( ) gets it and 
> updates it to represent the new file.  The try block does not set 
> 'getcontenttype' or 'getcontentlanguage' when updating an old 
> descriptor or even when creating a new one.
> 
> Seems like the PutMethod needs to be a little more discriminating when 
> retrieving an oldRevisionDescriptor and, in the case where a new one 
> is created, needs to add the 'getcontenttype' and 'getcontentlanguage' 
> properties.
> 
> What do you think?
> 
>   Marty
> 
> Martin Gronberg wrote:
> 
>> Env: Slide 1.0.9, Tomcat 3.2.1, Linux RedHat 6.2
>> 
>> Problem: When saving a MSWord document from MSWord | Save As... the 
>> file is stored without the 'getcontenttype' and 'getcontentlanguage' 
>> properties.
>> 
>> When I save a file using the MSWin2K File Explorer all the properties 
>> are created and saved including the 'getcontenttype' and 
>> 'getcontentlanguage' but not when I save using MSWord.  I was looking 
>> at the code and it seems like the PutMethod.executeRequest( ) should 
>> always add these properties to the revisionDescriptor for new 
>> objects.  Any ideas as to what could be going on?
>> 
>>   Marty
> 
>