On Jul 19, 2008, at 5:41 AM, Stephan Koops wrote:
> Hi Marc,
>>> sorry, you misunderstood me; perhaps I wrote not clear enough.
>>> It was meant for a message body READER. Must the InputStream
>>> (given to the message body reader by the runtime) reaches its end,
>>> if the length is reached, or must every provider check the length
>>> from the content-length header and stop itself.
>>> If the runtime environment gives only an InputStream with the
>>> length the provider should read, than the message body readers are
>>> easier to implement and could be used to read "multipart/whatever"
>>> data. Then the multipart provider only must ensure, that the
>>> InputStream given to the readers for every part closes, if the
>>> length of the content of this part is reached.
>> Seems a little heavyweight to me.
> Someone must ensure that the InputStream ends. In HTTP/1.0 it's the
> really end of the InputStream. In HTTP/1.1 someone must be
> responsible to stop reading from the net. If the JAX-RS runtime
> environment must ensure this (perhaps the used http container
> ensures it), then the message body readers are very simple. I think
> this is the way it works now; but I found now definition of it in
> the spec or javadoc.
>
> The multipart/whatever provider is enhanced, and not a part for the
> specifcation and not required for a runtime environment. It should
> only show other possibilities for it.
>
+1, I'll add a note to the javadoc that the caller is responsible for
ensuring that the input stream ends.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.