users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: get rid of getSize/Length

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 18 Jan 2013 21:47:09 +0000

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