Yep, something like that, just not HEAD, rather GET with
If-Modified-Since header.
> o what I think is REALLY URGENTLY NEEDED is another way to handle
> GET requests. I'd asked that before but got no answer. I don't
> see any problems in requesting more than one document within
> one server connection. BUT currently all servers close the connection
> after the last byte sent, EVEN if there is a Content-length: field.
> I'd like to propose that if there is such a field the client
> has to close the connection if it doesn't want more documents from
> that server or be able to send another GET or whatever!
> (but maybe this should be discussed under another subject).
Currently all the clients I know of do not use Content-Length -- Mosaic
reads it to give info of how many bytes of how many have been received
but still, the closing of connection is used to indicate end-of-document
(Content-Length could even be wrong and it still works).
So in other words server relying on this will not work. Therefore, clients
somehow need to indicate that they are willing to respect Content-Length.
I'm not too much against this idea, let's just see what the others think.
> o one great idea is the conditionally GET via If-Modified-Since:
> The only problem I see currently is: how do I determine as
> forwarder or client if the other side supports it?
Rob said he supports it in ncsa_httpd 1.2 out soon, I will support
it in cern_httpd 2.17beta out soon, and Tony Sanders certainly "adds
support for this into Plexus" before we know it... :-) Big sites
usually upgrade their servers pretty fast, so by the time we have a
good caching system all the major sites support conditional GET.
-- Cheers, Ari --