Paul,
since the HTTP specification does not enforce that any request must have a
body with a size larger than zero bytes, JAX-RS should not enforce this. So
if JAX-RS wants to provide a means for applications to deal with this issue,
my proposal is that the default is to inject null. If there is an
application that is unable to deal with that, it must check for null. This
is straightforward interpretation of the HTTP specification. It is ok if you
want to add an optional annotation that will prevent calling a method in
case of a null body. But since that is the exception (from the HTTP
specification view) the default must be to inject null.
For the Content-Type: It is valid to provide a content type even with a
missing body. The HTTP specification does not say that Concent-Type may only
be sent if Content-Length is larger than zero. So I do not see the problem.
If a client does not send a Content-Type but sends an empty body it is
obvious that the client does not care about any content type specific
behaviour. But I do not see that this is related to the zero-bytes-content,
since a client today could send a non-empty body with missing Content-Type
and no mathing file extension, and then you also do not know which method to
call. So this problem is not releated to the zero-bytes-problem. Your
proposal of ConsumesNothing is great, but it is independent of the
content-length. It solves a different problem.
Regards
Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Donnerstag, 11. Dezember 2008 10:32
To: dev_at_jersey.dev.java.net
Subject: Re: [Jersey] JAX-RS based WebDAV support
On Dec 10, 2008, at 7:51 PM, Markus KARG wrote:
Paul,
I do not see that 400 would be a correct return code, since 400 means "The
request could not be understood by the server DUE TO MALFORMED SYNTAX.". The
syntax was not malformed, it was pretty correct!
It depends on what you want to do. The syntax of the request may well be
malformed because a request entity is absent but a request entity is
required. The malformed syntax applies to the whole request and not just to
the syntax of request entity.
As you point out it is correct for a WebDAV method (i presume it is allowed
in the specification?) but for another application a HTTP method may require
a request entity and in this case having the application have to check for
null would be annoying when the framework could do that.
So still I believe that nobody out there would say something against a
single solution of injecting null.
You mean a default solution or an optional solution?
Maybe we should let people vote? ;-)
:-) i think it requires more discussion/exploration of the best way to
provide such a solution.
Part of the difficultly i am having with arriving at a solution is a method
such as:
@POST
@Consumes("application/xml")
public void post(String xxx) {
}
states that it consumes something. Now if i have two method consuming
something:
@POST
@Consumes("application/xml")
public void post(String xxx) {
}
@POST
@Consumes("application/json")
public void post(String xxx) {
}
then if the Content-Type is absent then which method would get called? we
need a way to state that one of these method may be called if the
Content-Type is absent or another method that gets called when the
Content-Type is absent, for example:
@POST
@ConsumesNothing
public void post() {
}
And we need to define the case of what happens when the Content-Type is
present but the content length is 0.
In the WebDAV case is the Content-Type absent from the request?
Paul.
Regards
Markus
For the issue with the empty bodies: We need to find a solution since it's
really a black spot on the overall great API. I think it would be not much a
problem to convince everybody that it makes more sense to inject null
instead of throwing a NullPointerException? :-)
Yes, i can see it both ways. Sometimes you want a null value to be
propagated and sometimes you do not and want a 400 response instead (the
latter probably being the most common i suspect).
One solution is to have a separate resource method for a request that does
not contain a request entity. Another could be to annotation the request
entity or the resource method that declares if there is not content-type
then the entity should be assigned a null value. I think i prefer the latter
solution.
Paul.