[6442] in www-talk@info.cern.ch
Re: An MGET proposal for HTTP
daemon@ATHENA.MIT.EDU (Chris Lilley, Computer Graphics Un)
Mon Oct 31 07:40:28 1994
Date: Mon, 31 Oct 1994 13:30:08 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Guy Decoux said:
> John Franks said:
> Proposal for an HTTP MGET Method
>> C: GET /foo.html HTTP/2.0<CRLF>
>> Accept: text/html, text/plain<CRLF>
^^^^^^^^^^^^^^^^^^^^^
>> S: HTTP/2.0 200 Success<CRLF>
>> Content-Type: text/html<CRLF>
> If one of my CGI scripts receive this header line, it send a document
> without inline image (no "image/gif", ... in the Accept fields) and you
> don't need to have a MGET :-)
I think there has been an uncertainty all along about whether Accept lines
should change between requests.
If you take the view that they don't, then the optimisation that Guy speaks
of is reasonable. Although what his scripts do with, say
text/html, text/plain, image/*
or
text/html, text/plain, */*
would be interesting to discover. On the other hand, does that mean that a
client that sends
GET document.whatever HTTP/version
Accept: text/html, text/plain, image/gif
is going to be happy getting a rasterised image of the page as a GIF?
If you take the alternative view that accept lines refer to the current
request, then Guy's optimisation is incorrect. It does however allow the
client, or possibly the user of that client, to specify what format they
would like a particular file delivered in (not just inline images, other
files too).
The problem is that format negotiation has not been widely deployed, so
whatever rubbish clients sent in their Accept headers made no material
difference.
--
Chris
