>>>
>>
>> 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...
That was actually a bad example, but hope you see what I meant anyway,
one may need to make a decision on how to proceed based on the info from
both request & response headers
>
> Having two different interfaces representing the request & response
> headers will help, we will just get two relevant contexts injected
>
> Cheers, Sergey
>
>>
>> Bill
>>
>
>