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.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
