On Jan 18, 2013, at 10:47 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Hi,
> On 18/01/13 18:27, Marek Potociar wrote:
>>
>> On Jan 18, 2013, at 11:14 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>
>>> 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[]).
>>
>> I'm sorry, but this does not seem to be the problem of the API or ignoring getSize(). Sure there is a way how you can include the C-L header even if you ignore getSize(). We all (implementors) have to find our ways how to do it...
>>
>>>
>>> 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
>>
>> Again: It's IMO much better to ignore getSize and deal with the C-L value in another (more robust) way than to go into complications of defining a conditional support for getSize().
>>
> I'm fine with the spec not requiring to check getSize(), but if possible, I'd really prefer the spec not explicitly prohibiting it; via some local configuration I can get getSize() utilized optionally without affecting the compatibility;
You can of course do that, but you need to make sure your users know it's not portable. Spec needs to ensure the applications written against API are portable. The choice to implement such proprietary switch in your impl., is, of course, up to you. But I do not think we should make the spec less strict as such.
Marek
> Having it set in the custom interceptor would work though again, such an interceptor would probably need to know if it is safe to do so or not
>
>
> Cheers, Sergey
>
>
>
>> Marek
>>
>>> 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?
>>>>>>
>>>>>>
>>>>
>>>
>>