- From: Dave Kristol <dmk@allegra.att.com>
- Date: Wed, 11 Jan 95 10:49:23 EST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I've been patiently watching the discussion of Accept-Parameter, et al., and waiting for someone to mention my extensions proposal (http://www.research.att.com/~dmk/extend.html) as a possible approach. Since no one did, I will. I hate to see HTTP cluttered with a bunch of rarely-used headers. At the risk of using more characters (Roy Fielding's caution noted), Accept-Parameter could be rendered (from the client): Extension: HTTP/charset required=oneof; set=UNICODE-1-1-UTF-8 Extension: HTTP/charset required=oneof; set=iso-8859-* The server would either respond with a similar header, like Extension: HTTP/charset set=UNICODE-1-1-UTF-8 to identify what was used, or it would return a failure, because neither of the required sets was supported. An Extensions:-unaware server would ignore the header and return none, and the client would have to fend for itself, as it does now. Roy Fielding said: > >> Also, a quality attribute is > >> only useful if we add it to the content-negotiation algorithm -- > >> something I would like to avoid (like the plague that it has become). > Pre-emptive content negotiation just doesn't work. Perhaps we should try > to define a matrix of common client characteristics/behavior, and just > provide a header for that.... The matrix approach is interesting (rather than negotiate each little item). My Extensions: proposal includes a negotiation algorithm. I think it would be better to settle on a single algorithm than have a different one for each thing to be negotiated. Perhaps the one I've proposed is unsatisfactory. I'm open to improvements. Nevertheless, I think there will be things in HTTP that will demand negotiation. Dave Kristol
Received on Wednesday, 11 January 1995 07:59:31 UTC