Re: Protocol Benchmarking (shortened :-)
hoesel@chem.rug.nl (frans van hoesel)
From: hoesel@chem.rug.nl (frans van hoesel)
Message-id: <9402030129.AA01817@Xtreme>
Subject: Re: Protocol Benchmarking (shortened :-)
To: montulli@stat1.cc.ukans.edu (Lou Montulli)
Date: Thu, 3 Feb 1994 02:29:10 +0100 (MET)
Cc: www-talk@www0.cern.ch
In-reply-to: <9402030037.AA23076@stat1.cc.ukans.edu> from "Lou Montulli" at Feb 2, 94 06:37:06 pm
X-Mailer: ELM [version 2.4 PL5]
Content-Type: text
Content-Length: 1458
lou wrote:
> Since Kevin and I were discussing this about half an hour ago, I
> might as well put in my 4 or 5 cents worth. (inflation :)
>
> If the host sent back the type immediately after the client sends
> the get, the client could check it's list of accepts to see if
> it's an acceptable type, for instance "image/jpeg".
> If the type is acceptable, the client responds, "OK
> send me the data", otherwise the client says "I don't understand
> image/jpeg" but I do understand "image/gif and image/x-xbm".
> If the server can deliver those types then he sends the data,
> if not then the server may attempt a different sub-group, for
> instance "application/x-mac-draw". In each case the client
> would only send the accept header of the specified sub-group,
> thereby saving the broadcast of a very large group of accepts.
>
> This form of negotiation would also be useful for Authorization,
> charge back, etc., since each of them would benifit by not
> having to open the connection twice. (currently Authorization
> must first be rejected by an authorized server and then retry
> with a password)
>
but isn't it a 'nice' feature of http that it doesn't need to keep connections
to the client open, so it cannot wait for the client to respond with "OK".
If it could, then it could also wait a bit longer so the MGET
suggetion (or the multipart request or whatever) isn't needed at all!
- frans
(just my $2 (If I were paid by the hour :-))