Re: Possible New Optional Field in Header?

On Tue, 9 May 1995, Levine, David M. wrote:
> I'd like to propose a new field in the request header.
> This would be totally optional, like "Referer".
> Many CGI scripts now use the UserAgent field to determine
> whether to send an inline GIF or JPG, based on the type
> of browser being used.  I'd like a field (called
> perhaps "XferRate") which would list the speed (in bytes
> per second) that the browser claims it is receiving
> data at.

First, should proposals like this be on http-wg or www-talk?  There's low 
enough traffic here that subjects not directly related to RFC status 
don't appear to be problematic, but as soon as Henrik or Dave or Roy yell 
to take it elsewhere, I'll happily comply :)

Back to the proposal: the problem is that "bandwidth" is much more that just
how fast your connection is.  For example, I'm hooked up to Sprint's and
MCI's backbone via three T1's to my desk, and I sometimes see object transfer
rates of 140k/second from nearby hosts, but there are times in the middle of
the day when the backbone is heavily loaded that I don't get better than
2k/sec even from hosts at large well-connected universities.  So, specifying
my connection speed in an HTTP header doesn't seem to be the smartest thing
in the world.  Additionally, just because I have a fat pipe doesn't mean I
necessarily want to see pages with 300K of inlined images and backgrounds. 

What's needed is a more general quality value, between 0 and 1 inclusive,
which expresses how much bandwidth I'd like to soak up.  This could be
implemented as a "cyberspace volume control" knob on my browser - I could
even set it per top-level domain (i.e., .9 for .edu sites, .1 for .uk or .it)
This would be akin to the q values on objects in the Accept class of headers,
so it would be nice if this could be made an attribute of a current request
header rather than its own header, but I don't see an obvious candidate. 

What servers do when they get a q value is entirely up to them of course, but
the smart ones will be rewarded for it with happier clients, so there is
incentive.  Already these days you see lots of pages with "click here for a
lower-bandwidth set of pages".  

Throw this in the 1.1 bin, I guess.

Also, a question for the HTTP gurus - if an object has variants based on 
different HTTP headers, is there some way a client could get a canonical 
list of those variants, and the rules they are served on?  Could this be 
a goal for extending the HEAD method, or is a new method called for?  I 
think this would be *very* useful for proxy caches.


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  http://www.[hyperreal,organic].com/

Received on Tuesday, 9 May 1995 14:28:49 UTC