Hi Bill
On 12/04/12 23:32, Bill Burke wrote:
>
>
> On 4/12/12 8:46 AM, Marek Potociar wrote:
>>
>> On Apr 11, 2012, at 7:32 PM, Bill Burke wrote:
>>
>>>
>>>
>>> On 4/11/12 8:04 AM, Marek Potociar wrote:
>>>>>> My understanding is that properties are for communication between
>>>>>> filters and handlers, i.e. properties are part of each single
>>>>>> request context but not part of the request or response objects in
>>>>>> the context. What is the use case for having the properties
>>>>>> available in the response?
>>>>>>
>>>>>
>>>>> Well, you may need to pass information to WriterInterceptors. for
>>>>> example, if you want to sign or encrypt the entity, you might want
>>>>> to pass through a cryptographic key.
>>>>
>>>> Interceptors can already access the properties via context.
>>>>
>>>
>>> How would application code be able to pass the cryptographic key into
>>> response processing without a properties map on Response? On the
>>> client side, the Configuration is available to pass through
>>> per-request objects. There's nothing available on the server side.
>>
>> I thought you would do the encryption via filters only. Why would the
>> resource business logic deal with cryptographic keys directly? Perhaps
>> I don't understand the exact use case you have in mind?
>>
>
> Well, we have a content-signature header (DOSETA) that was support. You
> may or may not want to sign the entity depending on the resource. What
> key you use may require logic specific to the request/resource. This is
> just one example though.
>
> But that's besides the point. I think a way to propagate per-request
> config/metadata is essential. I don't understand why you are balking at
> this so vehemently. Its a very simple addition.
I wonder if that would introduce an inconsistency similar to the one we
talked about earlier on, which you highlighted, where one would build
Response with the builder but then be able to modify Response headers.
Cheers, Sergey
>
> Bill
>