Bug 24005 - various issues with values of live properties
Summary: various issues with values of live properties
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Servlets:WebDAV (show other bugs)
Version: 4.1.27
Hardware: Other other
: P3 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL: http://greenbytes.de/tech/webdav/rfc2...
Depends on:
Reported: 2003-10-22 14:26 UTC by Julian Reschke
Modified: 2004-11-16 19:05 UTC (History)
0 users

Partial TC5 patch (4.61 KB, patch)
2003-11-15 22:47 UTC, Mark Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Reschke 2003-10-22 14:26:06 UTC
Consider a plain text file that responds to HEAD with:

ETag: W/"66-1066832095456"
Last-Modified: Wed, 22 Oct 2003 14:14:55 GMT
Content-Type: text/plain
Content-Length: 66
Date: Wed, 22 Oct 2003 14:16:44 GMT
Server: Apache Coyote/1.0

However PROPFIND returns:

1) <getcontentlanguage>de_DE</getcontentlanguage>
2) <getcontenttype>null</getcontenttype>
3) <getetag>66-1066832095456</getetag>

Re 1) If the content language is unknown, the DAV:getcontentlaguage header
should not be present. That's better than defaulting to a value which will be
wrong in many cases.

Re 2) If the content type is unknown, don't return the property. However, in
this case it seems that the server knows it (see HEAD response), thus the
property value should be the same.

Re 3) RFC2518 says that the value of DAV:getetag should be whatever GET/HEAD
return -- in this case quoting and the weakness indicator ('W/') are missing.
Comment 1 Mark Thomas 2003-11-15 22:45:32 UTC
I have had a look at this with partial success.
1) The default servlet never returns langauge information, so I have removed 
returning the language from the webdav servlet.
3) The webdav servlet had its own, less complete, method for determining the 
etag. I have removed this and modified the webdav servlet to use the default 
servlet implementation.

2) I have double-checked the code and all the places where content-type is 
returned (unless it is a null-resource where null is returned) uses exactly 
the same method as the default servlet. I can't figure this one out. Could you 
double check it? A example web-app that reproduces the problem would be a big 
help so I can debug it and trace the source.

I'll attach a patch that addresses 1 & 3.
Comment 2 Mark Thomas 2003-11-15 22:47:01 UTC
Created attachment 9129 [details]
Partial TC5 patch
Comment 3 Julian Reschke 2003-11-16 12:12:08 UTC
ok, here's a recipe to reproduce issue 2 (tested with 4.1.29):

- install tomcat
- enable write access on webdav
- connect Microsoft webfolder
- copy a file with no extension to /webdav/ (this causes a PUT request with not 
content-type header)
- PROPFIND on the resulting resource
Comment 4 Mark Thomas 2003-11-16 16:54:50 UTC
I have just check this with both TC4 and TC5 and the content type header is 
not returned. I have been having problems with the MS webfolders so I have 
been using telnet and I am 100% certain that the content-type header is not 
included in the response to HEAD in the circumstances you describe in 2.
Comment 5 Julian Reschke 2003-11-16 17:28:02 UTC
Maybe that's correct for HEAD, but I was doing a PROPFIND.
Comment 6 Mark Thomas 2003-11-20 21:26:02 UTC
Sorry, I didn't make myself clear in my last comment. The point I was trying 
to make was that HEAD didn't return a content-type header. Anyway, I have 
modified the return from PROPFIND so content-type is returned if it is null. 
This fix is included in the patch in 23999.

A complete patch for this bug (and 23999, 24001) is attached to bug23999.
Comment 7 Mark Thomas 2003-12-10 21:39:37 UTC
The necessary changes have been committed to CVS and will be included in the 
next release.