I want to add that Content-Type and Content-Length are independent
properties in both, HTTP and WebDAV. This is not a WebDAV specific problem
but common to HTTP.
There might be HTTP and / or WebDAV clients existing that send both, none,
or one of these headers at this is a pretty correct behaviour in ALL
applications since nobody enforces a file to have more then zero bytes!
The *actual* length of a body and it's *potential* type are unrelated. Why?
Because it is valid (at least on Windows) to create a zero-byte file on disk
*with a defined(!) type* (what is not possible on Unix since you always need
at least the prefixed magic byte to know the file type). When I want to
upload this empty file with HTTP PUT or POST, then I will send an empty body
plus Content-Type=text/plain plus Content-Length=0. This is absolutely
correct from the overall semantic.
So if a specific JAX-RS uses wants to enforce a length > 0 this is that
user's problem. I would NOT add a specific annotation or feature to JSR311
to enforce non-zeroness. IF (at all) JSR311 should add something then it
might be much more useful to add "generic" header filters (so I can filter
on anything), like this:
@HeaderFilter("Content-Length == 0 || My-Property == 'XYZ'")
But since I do not need this specials at all, still my proposal is to just
inject null and let that guy that so badly wants to have non-null add a
simple "if (body == null) throw WebApplicationException()" to his code.
Regards
Markus
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke_at_gmx.de]
> Sent: Donnerstag, 11. Dezember 2008 14:26
> To: dev_at_jersey.dev.java.net
> Subject: Re: [Jersey] JAX-RS based WebDAV support
>
> Paul Sandoz wrote:
> > ...
> > In the WebDAV case is the Content-Type absent from the request?
> > ...
>
> It depends. I'm pretty sure there are clients out there that set the
> content type even though the body is empty, but also other clients that
> don't.
>
> Similarly, there may be use cases where PUT is sent with an empty body,
> with or without content type.
>
> BR, Julian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net