Paul,
oops, seem's you're right. Strange that all currently tested WebDAV client's
don't care about this. On the other hand, the spec doesn't say that it must
be the same value in both cases, just that the property must be provided:
Since both operations could be interrupted by a second client modifying the
length (as LOCKing is not mandatory in WebDAV), it wouldn't make sense
anyways.
BTW, just for anybody interested in it: Just finished performance tests with
WebDAV ontop Jersey. Directly listing in Vista FileExplorer (1000 "files"
taken from a embedded derby db using JPA via Jersey) on a dual core laptop
needs just a quarter of a second. For comparison: The same machine needs
several seconds to provide the same view using it's local physical NTFS.
That's just gread. :-) Strange but true, using a single thread and storing
the XML byte stream in RAM to later rewrite it is two times faster than
using two threads working in parallel using Piped*Stream or
BlockedLinkedList<ByteBuffer> -- Java's memory management seems to be
lightning fast, compared to a Thread context change (even when using
Executors.newChachedThreadPool)! Daniel worked hard on support for Windows
7, W2K3 and Office WebDAV clients, and I fixed Vista support. Seems all
current Windows OSs work well and fast now. We'll release all fixes within
2009, so in 2010 people can have complete and performance optimized "file"
API based access to their server side data. Looks like we'll have a big
party on dec 31! :-D
Regards
Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Dienstag, 29. Dezember 2009 16:26
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] How to find out content-length *before* unmarshalling?
On Dec 29, 2009, at 4:21 PM, Markus Karg wrote:
Paul,
actually consistence is not the problem:
The byte count ("length") returned inside the response entity of a PROPFIND
is the "pure" ("net") length of the actual data,
I was referring to the following:
http://www.webdav.org/specs/rfc2518.html#PROPERTY_getcontentlength
"The getcontentlength property MUST be defined on any DAV compliant
resource that returns the Content-Length header in
response to a GET."
Paul.
while content-length is the "wrapped" ("gross") length, which the WebDAV
client is not interested in. The length is just used to transport
human-readable information, it has no technical implication, as the actual
content transport happens in a later GET -- which is is "simple and correct"
http GET. In PROPFIND, you can even provide a zero, it will work. ;-)
Regards
Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Dienstag, 29. Dezember 2009 15:58
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] How to find out content-length *before* unmarshalling?
On Dec 29, 2009, at 3:20 PM, Markus Karg wrote:
Paul,
you're already back from Holidays? :-)
Yes, just for today and tomorrow then back to work next Monday.
Thank you for your proposal, it sounds interesting, but unfortunately we
cannot use it since it is not part of JAX-RS. :-( Seems I should file
another RFE for JAX-RS 2.0. :-)
I can only think that for such cases like WebDAV it may make sense to be
able to make internal requests whose responses can be collated (which is not
particular efficient for large collections of resources).
The content length is not really needed, it is just on a wish list: WebDAV
can return the size of a file (in byte) when doing a PROPFIND (i. e.
something like DOS's "DIR"). Currently our sample application always returns
0, but it would be smart to return the real size. Just because it would be
nice. No real need. I think there is no really good solution. In case we
have a directory containing thousands of files, it would just need too long
time to stream them to dev/null just to find out their size. Obviously this
cannot be prevented, unless JAXB would know something like a
"Marshaller.getSizeWithoutActualStreaming()" command. ;-)
To be consistent in such cases you would also have to return the
Content-Length response header for a GET on the associated DAV resource. So
you will need to switch chunked transport encoding off, which will require
some setting at the level of the Web or App server.
IMHO such a property does not make much sense for "computational WebDAV
resources" (the length may not be constant for long periods of time) and
just makes things more inefficient and how useful is it to clients even
humans when using a WebDAV file browser [*]?
Paul.
[*] I suspect that is where the "it would be nice" comes from.