Re: [RFC] Optional header negotitation

On lör, 2007-08-18 at 14:12 +0300, Stefanos Harhalakis wrote:

> a) I already proposed that and the feedback I got indicated that there
> is 
> concern about the additional overhead it will introduce.

The overhead is only a minor concern. It's not a big deal. For things
like timezone the overhead of always sending this is fairly small.

The main concern is privacy and extending the protocol with mechanisms
designed to give out more information about the user without the user
knowing about it.

This said I don't see much wrong with the proposal. In fact I like if
for the context it's intended to be used as it allows for the user-agent
to implement a simple workflow to build a profile of the users security
preferences similar to what is already implemented in most useragents
for cookies. Just make the refresh optional, only needed if the response
Vary on the requested header.

> I'm also considering the possibility that this method will be used by
> *both* 
> ends to request additional headers. For example, if we could travel
> back in 
> time and perform some changes, clients could be able to request the
> 'Server' 
> and 'Date' headers on demand.

Lets leave this for the context of user related request headers. Yes, it
may be used for other purposes as well, but can't think of many such use
cases where it do make good sense outside user related information and
privacy protection.

Most other headers is better to always send when available.. as is done
today.

Regards
Henrik

Received on Wednesday, 22 August 2007 22:57:21 UTC