- From: M. Hedlund <hedlund@best.com>
- Date: Mon, 29 Jan 1996 12:21:15 -0800 (PST)
- To: David Ornstein <davido@apocalypse.org>
- Cc: www-talk@w3.org
On Mon, 29 Jan 1996, David Ornstein wrote: > At 10:12 AM 1/29/96 -0800, M. Hedlund wrote: > >OR logic could be specified by giving more than one PARAM. AND logic > >could be specified by recursive INSERTS. Browsers that don't recognize > ><INSERT> get the fallback text. > > Achieving AND and OR this way might (I can't quite get it clear in my head) > get in the way of clean (proxy-server) caching. I don't think so.....the browser is just sending out a GET. The logic which caused it to make that GET is irrelevant to the cache controller. > Everything is a tradeoff, but I'll point out that this has a > performance-related predisposition towards browsers that don't understart > the new construct. Yes, that's true, but browsers that recognize conditional INSERTs are also much more likely to be able to request Keep-Alive connections. In other words, browsers that can make conditional GETs get probably also avoid the start-up and tear-down times associated with them. > Because the fall-back form (<P>Your browser doesn't recognize > vendor-tables/1.1, so you're seeing this instead.</P> in the example > above) is always sent, browsers that *do* understand the new construct > will be, in a sense, penalized by being forced to do the extra GET (and > having to have spent extra transport time getting the unneeded fall-back). The fall-back is short. It seems a small price to pay. ;) Marc Hedlund <hedlund@best.com>, <marc@organic.com>
Received on Monday, 29 January 1996 15:25:02 UTC