Re: An MGET proposal for HTTP

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Wed, 2 Nov 1994 05:40:34 +0100

Thus wrote: ts
>> This is an excellent example of how we do NOT want to see HTTP
>> progressing, such that clients say things they don't really mean and
>> servers try to read clients' minds. A client should not send */*
>> unless it really means it, and a server should take it at face value.
>> This is supposed to be data transfer, not artificial intelligence.
>
> Because I don't want that an user can receive this :
>
>moulon% www http://www.whitehouse.gov/
> Welcome to the White Hous
>e
> [1]
>
> Choose this[2] for a textual representation of this page.
> [ etc etc ]

Yes, of course that's ugly. The proper solution would be to have
something like a <FIG> tag which is a wrapper, and inside the wrapper
could go a complete textual representation of the page as a list or
menu or whatever. We'll continue to have these problems until <IMG>
is dead and buried and replaced by something that's well-designed.
But this is a problem to be solved at the HTML level, not the HTTP
level.

> I think that my script is better than this server.

Er, actually, lots of Lynx clients send "image/gif" in the Accept:
field, depending how the mailcap file is configured. The inclusion of
"image/gif" absolutely does not tell you that a viewer can display
inlined images, nor does its absence tell you a viewer cannot do so.
Somebody may actually make a client that (gasp!) realizes that if you
send */* in an Accept: field there is no point in sending anything
else unless there are some additional values.

Your script is the HTTP equivalent of using invisible GIFs to try to
center text; whether that's a good or bad thing is a religious
question, but it's certainly a brittle thing.

(Now, how long until somebody invents an HTTP equivalent to colored
balls as list bullets? :-)

--
Marc VanHeyningen  <http://www.cs.indiana.edu/hyplan/mvanheyn.html>