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, 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.