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.