On Wed, 2010-03-24 at 12:54 +0100, Oleg Kalnichevski wrote:
> 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
>
Looks good thanks!
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
