Bug 56693 - non-rfc conform delayed file operations with webdav
non-rfc conform delayed file operations with webdav
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: Catalina
8.0.x-trunk
PC Linux
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-07-03 08:15 UTC by aidbmfqognnq6gizaigaqaaaaaaaa
Modified: 2014-07-03 14:31 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aidbmfqognnq6gizaigaqaaaaaaaa 2014-07-03 08:15:16 UTC
When uploading a file using webdav in Tomcat 8.0.9 it doesn't show up immediately even though the server responds with "201 created".

This results in a 404 or even 500 on operations on a file that is supposed to be available on the server.

Disabling the static resource caching in the context didn't help. Tomcat 6.0.41 and 7.0.54 act normally.

According to rfc, if the server delays the file creation it should return a 202 accepted, not a 201 created.


Examples:

(1)
> dav:/webdav/> ls
> Listing collection `/webdav/': collection is empty.
> dav:/webdav/> put testfile.bin
> Uploading testfile.bin to `/webdav/testfile.bin':
> Progress: [=============================>] 100,0% of 102400 bytes succeeded.
> dav:/webdav/> propget testfile.bin
> Fetching properties for `testfile.bin': failed:
> 404 Not Found

[now I'm waiting for a couple of seconds]

> dav:/webdav/> propget testfile.bin
> Fetching properties for `testfile.bin':
> DAV: creationdate = 2014-07-01T16:29:35Z
> DAV: displayname = testfile.bin
> DAV: getlastmodified = Tue, 01 Jul 2014 16:29:35 GMT
> DAV: getcontentlength = 102400
> DAV: getcontenttype = application/octet-stream
> DAV: getetag = W/"102400-1404232175000"
> DAV: resourcetype =
> DAV: source =
> DAV: supportedlock = <DAV:lockentry><DAV:lockscope><DAV:exclusive></DAV:exclusive></DAV:lockscope><DAV:locktype><DAV:write></DAV:write></DAV:locktype></DAV:lockentry><DAV:lockentry><DAV:lockscope><DAV:shared></DAV:shared></DAV:lockscope><DAV:locktype><DAV:write></DAV:write></DAV:locktype></DAV:lockentry> 

(2)
> dav:/webdav/> rm testfile.bin
> Deleting `testfile.bin': succeeded.
> dav:/webdav/> ls
> Listing collection `/webdav/': collection is empty.
> dav:/webdav/> put testfile.bin testfile.bin.tmp
> Uploading testfile.bin to `/webdav/testfile.bin.tmp':
> Progress: [=============================>] 100,0% of 102400 bytes succeeded.
> dav:/webdav/> move testfile.bin.tmp testfile.bin
> Moving `/webdav/testfile.bin.tmp' to `/webdav/testfile.bin':  failed:
> 500 Internal Server Error

[again, waiting for a couple of seconds]

> dav:/webdav/> move testfile.bin.tmp testfile.bin
> Moving `/webdav/testfile.bin.tmp' to `/webdav/testfile.bin':  succeeded.


my web.xml:
--%snip%--
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
	version="2.5">

	<display-name>webdav</display-name>
	<description>webdav access</description>

	<servlet>
		<servlet-name>webdav</servlet-name>
		<servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class>
		<init-param>
			<param-name>debug</param-name>
			<param-value>0</param-value>
		</init-param>
		<init-param>
			<param-name>listings</param-name>
			<param-value>true</param-value>
		</init-param>
		<init-param>
			<param-name>readonly</param-name>
			<param-value>false</param-value>
		</init-param>
	</servlet>

	<servlet-mapping>
		<servlet-name>webdav</servlet-name>
		<url-pattern>/*</url-pattern>
	</servlet-mapping>


	<security-constraint>
		<web-resource-collection>
			<web-resource-name>WebDAV</web-resource-name>
			<url-pattern>/*</url-pattern>
			<http-method>CANCELUPLOAD</http-method>
			<http-method>CHECKIN</http-method>
			<http-method>CHECKOUT</http-method>
			<http-method>COPY</http-method>
			<http-method>DELETE</http-method>
			<http-method>GET</http-method>
			<http-method>GETLIB</http-method>
			<http-method>HEAD</http-method>
			<http-method>LOCK</http-method>
			<http-method>MKCOL</http-method>
			<http-method>MOVE</http-method>
			<http-method>PROPFIND</http-method>
			<http-method>PROPPATCH</http-method>
			<http-method>PUT</http-method>
			<http-method>REPORT</http-method>
			<http-method>UNCHECKOUT</http-method>
			<http-method>UNLOCK</http-method>
			<http-method>UPDATE</http-method>
			<http-method>VERSION-CONTROL</http-method>
		</web-resource-collection>
		<auth-constraint>
			<role-name>*</role-name>
		</auth-constraint>
	</security-constraint>

	<login-config>
		<auth-method>BASIC</auth-method>
		<realm-name>WebDAV</realm-name>
	</login-config>

	<security-role>
		<description>WebDAV User</description>
		<role-name>webdav</role-name>
	</security-role>

	<distributable />
</web-app>
--%snip%--
Comment 1 Konstantin Kolinko 2014-07-03 09:33:57 UTC
(In reply to aidbmfqognnq6gizaigaqaaaaaaaa from comment #0)
> 
> Disabling the static resource caching in the context didn't help.

Did you read my answer?
http://markmail.org/message/tm5acr27a6j6hfga

You did it wrong. There is no such attribute as "cachingAllowed" on Context in Tomcat 8.

The attribute was moved to nested <Resources> element.
http://tomcat.apache.org/migration-8.html#Web_application_resources
Comment 2 aidbmfqognnq6gizaigaqaaaaaaaa 2014-07-03 12:47:44 UTC
Hi Konstantin,

thanks for your reply, that email you mentioned sadly never arrived here.

As I'm not familiar enough with it, is the right way to add a META-INF/context.xml containing
> <Context>
> <Resource name="org.apache.catalina.servlets.WebdavServlet" cachingAllowed="false" />
> </Context>
?

If that's the case -- it didn't help.

Regardless of whether or not disabling the cache may help, if the file is not ready for immediate access after upload tomcat should return a "202 accepted", not a "201 created".
Comment 3 Mark Thomas 2014-07-03 14:31:32 UTC
It was the static resource cache that wasn't invalidating cache entries when it knew the current entry was invalid. This has been fixed in 8.0.x for 8.0.10 onwards.

I have also fixed a handful of other failures identified by the Litmus WebDAV testsuite.