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?
>
>