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.