Re: HTTP2 spec

Dave_Raggett ([email protected])
Mon, 4 Jan 93 14:11:19 GMT


> allowing such extensions as
>
> GET /junk/mydoc HTRQ/1.0
> From: Tim Berners-Lee <[email protected]>
> Accept: text/plain, text/html, image/GIF(0.0,.5)
> Accept-Encoding: X-Compress, base64, X-tar, X-Nextmail
>
> with reponse
>
> HTTP-Version: 1.0
> Response: OK
> MIME-Content-type: image/GIF
> Allow: GET, PUT, TEXTSEARCH
> Public: GET, TEXTSEARCH
>
>etc etc.

I hope to give more detailed feedback soon, but an immediate suggestion is
to include a size field giving the number of bytes in the complete message
(or an estimate). This would allow the browser to show a gauge indicating
how much of the message has been received at any time (I want to temporarily
replace the vertical scroll bar by a bas-relief thermometer). The gauge
would only be shown if this size field is present.

This is helpful when getting a large document or when the comms link is
slow, e.g. if you are using a modem link. An additional benefit is in
helping the browser to manage its resources more effectively, e.g.
reduce need for reallocs and when to use a disk buffer rather than a memory
image for very large documents.

A second suggestion to improve the ergonomics of WWW is to let users know
when an expensive operation is being conducted by the server, e.g. document
format conversion, complex database search, or access via a "slow" gateway.
The underlying principle is that users don't mind if performance is slow
provided they know what to expect.

My suggestion is that part of the message header is sent before beginning
the document conversion (or whatever). The remainder and the document body
content is sent later. The part of the header sent earlier on includes a
processing attribute, e.g. "Processing: converting to html ..."

Best wishes for a happy new year,

Dave Raggett, hplabs, England