Re: HTTP-NG: status report

Brian Behlendorf (
Wed, 23 Nov 1994 02:26:36 +0100

On Tue, 22 Nov 1994, Gary Adams - Sun Microsystems Labs BOS wrote:
> > From [Brian Behlendorf,, on]
> >
> > The act of fetching inlined images could be made faster if the server
> > were able to tell the client directly in its response headers "I think
> > you'll want to get these items next" - that way the client doesn't have
> > to parse the document as it's coming down the pipe looking for inlined
> > images. I.e., in HTTP/1.0 terms (since I haven't seen the HTTP-NG terms)
> >
> > C: GET / HTTP/1.0
> >
> > S: ...
> > Inlined-objects-URI: /Images/yes.gif, /Images/no.gif
> > ...
> This is the place that I always get confused in separating out the responsibility
> of the protocol on the wire for HTTP and the features I expect to see supported
> from an HTML document authoring system. To follow from your example above the
> next objects transmitted over the wire would look like this :
> <HTML>
> <HEAD>
> <TITLE> Important to display this as soon as possible (warm fuzzies for users)</TITLE>
> ....
> <<Processing instructions, list of inlined images, list of related hrefs,... >>
> </HEAD>
> In other words, a document header is accessible with a minimal amount of
> processing and may contain equally valuable processsing instructions at
> an application level. If this information is in the HTML HEAD, it could be
> possible to acheive similar savings over other transport schemes (ftp, gopher,
> wais, etc.)

Well, remember that in the FHTTP model the delivery stream of the
document is separate from the delivery stream for the meta-information;
and if the client could completely avoid having to look in the document
delivery stream for pointers on what to do, that would seem to be a good
thing (though maybe I'm misinterpreting the model.)

Also, I think we should be thinking along the lines of making HTML and HTTP
as orthogonal as possible - HTTP should be as completely functional when the
WWW is SGML aware, too.

> If we intend for the server to parse documents and take action before the
> client has determined what they will do with the information, there will need
> to be some additional dialog upfront where the client can communicate its
> "intentions" about the information it has requested. e.g. I'd rather have
> 10,000 clients parse the document and determine what actions to take than
> to have the server parse the same document 10,000 times while the next 10,000
> requests are waiting.

Remember that I suggested the server only parse the document once and
cache that info for later accesses, not parse it with each access (though
doing a quick stat to see if the file had changed would be needed, but I
think that's done somewhere in the process anyways for the last-modified

> Best of all I'd rather have the document author wait
> while their document is checked for errors and optimized for rapid retrieval
> just once so all 10,000 of us could enjoy the benefits.

Which brings up the idea again that the HTML the client sees should possibly
be different than the HTML the author creates. That sounds fine, I'd
just counter that it might not be the right level of generalization....


Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3