On 20/09/12 17:00, Bill Burke wrote:
>
>
> On 9/20/2012 10:51 AM, Sergey Beryozkin wrote:
>> On 20/09/12 15:45, Bill Burke wrote:
>>>
>>>
>>> On 9/20/2012 10:15 AM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Sep 20, 2012, at 6:17 AM, Sergey Beryozkin wrote:
>>>>
>>>>> If MessageBodyReaders had the same capability to modify the input
>>>>> headers, then it would cause some minor issues I'm referring to below.
>>>>>
>>>>> Reader interceptors are effectively higher-level MBRs. IMHO that is
>>>>> another reason why they should not be able to modify the headers
>>>>
>>>> Off top of my head I can't think of any UC for which having writable
>>>> headers in the reader context would be useful.
>>>>
>>>
>>> Keep it mutable, IMO. I can see wanting to change the content-type (add
>>> a charset or something) or adding other headers that might trigger
>>> behavior in the MBR.
>>
>> Why this can not be done at the filter level ?
>>
>> What do you think of the concerns I had in the original email ?
>>
>> I mean, we can just say, whatever, won't really harm to be able to
>> update the headers from different chains, but it's a duplication, having
>> two options to do the same thing, it seems to me it is
>>
>
> I don't care that much. Whatever u guys decide is ok with me.
>
OK :-)
I reckon having some clear differentiation between interceptors and
filters (ex, interceptors can 'block' MBR/MBW) can help with making it
more obvious why we have interceptors in the first place. If the task of
modifying the in headers can be done from either of the places, filters
or readers, then it becomes less obvious....
Cheers, Sergey