Slow HTTP Responses

• Mail folder: WWW Talk Jan 94-present
• Next message: James (Eric) Tilton: "Re: Whitespace"
• Previous message: Paul "S." Wain: "Re: Whitespace"
• Reply: George Phillips: "Slow HTTP Responses"

Date: 13 Jan 94  1:55 -0800
From: George Phillips <phillips@cs.ubc.ca>
To: <www-talk@www0.cern.ch>
Message-id: <7165*phillips@cs.ubc.ca>
Subject: Slow HTTP Responses
Content-Length: 1741

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.