1) Add a new response header called "Status:". Whenever the browser
sees "Status:", it will report the string to the user. For example:
client says:
GET /archie?lynx HTTP/1.0
server responds:
HTTP/1.0 200 Document Follows
MIME-Version: 1.0
Status: 0 % of search done
... and after a bit
Status: 20 % of search done
... and a bit later
Status: 100 % done!
<TITLE>etc.etc.etc.
This is simple and simple to implement. Unfortunately, the server
can report a HTTP level-error if something goes wrong -- it has
already said that things are OK.
2) Make a new Content-Type: for HTTP responses (http/response?).
And a new reponse code 205 that triggers the browser to report
the status message. So you get server reponses like:
HTTP/1.0 205 Starting search...
MIME-Version: 1.0
Content-Type: http/response
HTTP/1.0 205 Search 10 % complete
MIME-Version: 1.0
Content-Type: http/response
etc.
A little trickier to implement, would probably enable libwww to
handle .http files, makes the reponses a bit verbose. Don't
take the "http/reponse" Content-Type: name too seriously - the
real solution will do better.
Any preferences or better ideas? I think the "http/reponse"
Content-Type: could have many collateral benefits as it frees
HTTP request/reponse from TCP/IP transports (mail servers, anyone?).
Both ideas are at least compatible with current practice
while not being too hard to do. I thought about a multipart/alternative
solution but quickly got scared away.