On 17/01/13 23:11, Bill Burke wrote:
> 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.
We have a user right now reporting the regression due to his client
application not seeing Content-Length any more where he knows that his
application does not uses GZIP and returns byte arrays (byte[]).
IMHO the 'probability' is not a good indicator of how useful getSize()
can be. I think the default providers should use -1 by default, but let
users configure their binary MBW when needed - all stacks offer the
integration options where injection specific properties into providers
can be possible so I'm not see any issues with keeping this method
Sergey
>
> 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?
>>>
>>>
>