On Tue, 2010-03-23 at 17:58 -0400, James Leigh wrote:
> On Tue, 2010-03-23 at 22:06 +0100, Oleg Kalnichevski wrote:
> > James Leigh wrote:
> > > On Tue, 2010-03-23 at 20:41 +0100, Oleg Kalnichevski wrote:
> > >> James Leigh wrote:
> > >>> Ah yes, it is okay. I think I was expecting the decoder to already be
> > >>> complete or to at least return -1 on the first read. No need to create a
> > >>> bug report as it is functioning as expected.
> > >>>
> > >>> Just so I understand this. In order to detect if a decoder has nothing
> > >>> to read you have to use the following condition (I guess that is how
> > >>> previous versions worked)?
> > >>>
> > >>> if (decoder.isCompleted()
> > >>> || decoder.read(ByteBuffer.allocate(0)) < 0
> > >>> || decoder.isCompleted()) {
> > >>> // nothing to read
> > >>> }
> > >>>
> > >> I would say decoder.isCompleted() alone should be enough. If the end of
> > >> stream condition (-1) is detected all decoders should set their state to
> > >> completed automatically.
> > >>
> > >> Cheers
> > >>
> > >> Oleg
> > >>
> > >
> > > Unless Content-Length is zero, then the decoder is not complete until
> > > after the first read method is called, which will return 0.
> > >
> >
> > Would you consider it more appropriate for the codec to set its state to
> > completed immediately if the content length is zero?
> >
> > Currently decoders of all types behave consistently. One need to do a
> > read from a decoder, be it chunk, identity or content length delimited,
> > in order to detect an empty stream. I would rather keep it this way.
> >
> > Oleg
>
> That makes sense, but I would expect the first read of a
> known-to-be-empty stream to return -1 on the first read.
>
Fair enough. I committed a fix to the SVN trunk. Please have a look.
http://svn.apache.org/viewvc?view=revision&revision=927019
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
