- From: Koen Holtman <koen@win.tue.nl>
- Date: Sat, 17 Aug 1996 01:15:48 +0200 (MET DST)
- To: Fisher Mark <FisherM@is3.indy.tce.com>
- Cc: dwm@shell.portal.com, koen@win.tue.nl, ses@tipper.oit.unc.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Fisher Mark:
>Koen Holtman:
>>As for the main problem discussed in this thread, how to share data
>>for negotiating around bugs the browser vendor does not care about: it
>>seems that an internet draft to solve this problem would have to
>>define a substantial amount of new stuff, beyond what is now in both
>>HTTP-NG negotiation and transparent negotiation.
>
>Since user agent negotiation is just a special case of content negotiation,
>we should definitely merge the two together for now.
Yes. There are actually two ways to layer browser bug negotiation on
top of transparent content negotiation.
Suppose browser PQ has `5dtables' in its profile (I support 5
dimensional tables), but that you know from your browser bug database
that the support for 5dtables in PQ2.3 is buggy. Knowing this, you can
a) filter incoming Accept-Features headers from the PQ2.3 browser
to change
Accept-Features: frames, 5dtables, *
into
Accept-Features: frames, !5dtables, *
b) filter or patch your variant lists to change the list
{"home.html.5d" 1.0 {features frames 5dtables}}
{"home.html.2d" 0.8 {features frames}}
{"home.html.1d" 0.7}
into
{"home.html.5d" 1.0 {features frames 5dtables !user-agent=PQ2.3}}
{"home.html.2d" 0.8 {features frames}}
{"home.html.0d" 0.7}
so that the first variant won't ever be chosen for PQ2.3.
I think that b) is best, in particular because this allows caching
proxies to do the browser bug negotiation, saving the RTT to the
origin server. With a collection of numeric and non-numeric feature
tags containing the name, version, major+minor version, and platform
of a browser, you would be able to do pretty good bug negotiation in a
cachable way. Provided of course that the user agent does not lie
when sending values for these feature tags.
Transparent content negotiation is suitable as a carrier mechanism for
bug negotiation. You can hand-edit your variant lists if you know
about certain browser bugs. But in a real bug negotiation
infrastructure, there would be no need to hand-edit your variant
lists: some standard software layer on your server would take care of
this automatically, using the latest knowledge about bugs. To get to
this level of automation, you would still have to define a substantial
amount of new stuff. You need to define a bug database format and a
way to merge bug databases for a start.
>Mark Leighton Fisher
Koen.
Received on Friday, 16 August 1996 16:18:00 UTC