Slow HTTP Responses

George Phillips (phillips@cs.ubc.ca)
13 Jan 94 10:37 -0800


Sometimes a server can take a long time to return a document because
it is doing something slow like an Archie search. It would be nice
if the server could give the client some kind of status information.
I have two suggestions on how to do that:

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.