Finishing the ContentEncoder

[Sam Berlin <sb...@gmail.com>]

Hi Folks,

I've got a situation where an HttpResponse can come without a
content-length set, but the application can determine when the entity
is 'finished' through reading it.  In HttpCore this is solvable by
closing the InputStream after reading what you need.  (It will use an
IdentityInputStream, and closing it is symantically equivalent to
ContentLengthInputStream reading its alloted length.)  In
HttpCore-NIO, I don't see a way to do this.  What about adding a new
interface, something like CompletableContentDecoder that extends
ContentDecoder, and having IdentityDecoder implement it -- the only
additional method would be 'setCompleted', and it would set completed
to true.  (Or just expose the method on IdentityDecoder and look for
that specific class.)  This'd let the rest of the NIO system know that
the decoder was finished.  An alternate approach is to add some hook
where the decoder is prepared to return your own kind of decoder...
but given that the blocking variant of httpcore lets you do this
easily on the stream/decoder, I think it makes sense for the
non-blocking variant to let it happen.

So, I'll go for the easy approach...  one additional method on
IdentityDecoder: setCompleted(boolean) that sets completed.  Think we
could sneak this one into beta2?  (Also, let me know if it's OK to
just commit a change like this without talk.)

Thanks.

 Sam

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: Finishing the ContentEncoder

[Sam Berlin <sb...@gmail.com>]

> What about closing the channel / IOSession? Would that work?

Unfortunately, no.  The reason completing the decoder works is that it
allows the channel/session to continue processing more messages.
Closing the channel/session would abort the connection (AFAIK).  It's
basically faking a content-length.

>>  (Also, let me know if it's OK to just commit a change like this without talk.)
> Sure thing.

Committed, thanks.

Sam

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: Finishing the ContentEncoder

[Oleg Kalnichevski <ol...@apache.org>]

On Sun, 2008-06-15 at 10:20 -0400, Sam Berlin wrote:
> Hi Folks,
> 
> I've got a situation where an HttpResponse can come without a
> content-length set, but the application can determine when the entity
> is 'finished' through reading it.  In HttpCore this is solvable by
> closing the InputStream after reading what you need.  (It will use an
> IdentityInputStream, and closing it is symantically equivalent to
> ContentLengthInputStream reading its alloted length.)  In
> HttpCore-NIO, I don't see a way to do this.

What about closing the channel / IOSession? Would that work?


>   What about adding a new
> interface, something like CompletableContentDecoder that extends
> ContentDecoder, and having IdentityDecoder implement it -- the only
> additional method would be 'setCompleted', and it would set completed
> to true.  (Or just expose the method on IdentityDecoder and look for
> that specific class.)  This'd let the rest of the NIO system know that
> the decoder was finished.  An alternate approach is to add some hook
> where the decoder is prepared to return your own kind of decoder...
> but given that the blocking variant of httpcore lets you do this
> easily on the stream/decoder, I think it makes sense for the
> non-blocking variant to let it happen.
> 
> So, I'll go for the easy approach...  one additional method on
> IdentityDecoder: setCompleted(boolean) that sets completed.  

I do not see a problem with that.

> Think we
> could sneak this one into beta2? 

Absolutely. We have mot even started the vote on the release, so we can
do whatever we please.

>  (Also, let me know if it's OK to
> just commit a change like this without talk.)
> 

Sure thing. 

Cheers

Oleg

> Thanks.
> 
>  Sam
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org