I still think getSize() should be banned/deprecated/ignored. Except for
primitives, String, and byte[] the only way getSize() can be calculated
is by buffering the entire message body and finding the length. Not
only that, but getSize() is called *BEFORE* writeTo().
I think gzip encoding has a much higher probability of being used than
any application that might require Content-Length.
On 1/17/2013 6:00 PM, Sergey Beryozkin wrote:
> Hi,
>
> two issues popped up recently during the internal discussions, where
> getSize() might be handy, possible HTTP Range support at the custom MBW
> level, and in cases where Content-Length is explicitly expected on the
> client side, so why returning something different than -1 from getSize()
> won't work with GZIP and such, the users should still have the option to
> return a positive value when it is known it will work
>
> Thanks, Sergey
> On 04/06/12 17:58, Bill Burke wrote:
>>
>>
>> On 6/4/12 10:38 AM, Santiago Pericas-Geertsen wrote:
>>>> I fixed a bug a few months ago where our container set the
>>>> Content-Length header based on MBW.getSize() and we had gzip encoding
>>>> on, so the value Content-Length ended up being wrong.
>>>
>>> What if we state that JAX-RS implementations must not update
>>> Content-Length after calling writeTo()?
>>>
>>
>> That doesn't cut it I don't think.
>>
>> Is my above case a problem with Resteasy? Or a problem with getSize()?
>> Content-Length reflects the actual bits on the wire right? So, if there
>> is any type of encoding, won't getSize() always be wrong?
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com