Hi
On 30/01/12 17:43, Bill Burke wrote:
>
>
> On 1/30/12 11:48 AM, Sergey Beryozkin wrote:
>> Hi,
>> On 30/01/12 16:34, Bill Burke wrote:
>>>
>>>
>>> On 1/30/12 11:21 AM, Marek Potociar wrote:
>>>> Let me know what are your thoughts on the whole subj.
>>>>
>>>
>>> I don't care that much, but, as I said before Request/Response have
>>> methods that don't make sense in different contexts I can see that the
>>> name of of some certain methods don't make sense on HttpHeaders (like
>>> getRequestHeaders()).
>>>
>>> Maybe a deprecated HttpHeaders and define a unified Headers interface?
>>> Request/ResponseHeaders are pretty much the same as it is.
>>>
>>
>> I'd go with two different interfaces given that some http headers are
>> not quite applicable in the client context, such as
>> getAcceptableMediaTypes, etc and I guess same can be said to some of the
>> headers in the server context.
>>
>
> Then I'd like to point out certain methods aren't applicable on Request
> and Response in certain context's i.e.:
>
> * readEntity for a client Request or a server Response
> * all the evaluatePreconditions methods on Request
> * bufferEntity() on server Response
> * close() on a server Response
>
>
> In fact, there are far more methods on Request/Response that don't make
> sense in certain context's than there would be with a unified
> HttpHeaders interface.
>
> I don't really care that much, just pointing this out.
>
One thing which became obvious to me today, though I had to deal with
such issues before, is that it can be important for a given filter to
deal with the current request and response headers in scope of the same
call.
For example, one may need to inspect the current Content-Type but it has
to be taken from either request or response headers...
Having two different interfaces representing the request & response
headers will help, we will just get two relevant contexts injected
Cheers, Sergey
>
> Bill
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com