XBITHACK, META. Buy one, get one free

[Rob Hartill <ha...@ooo.lanl.gov>]

> 
> Hey people.  I can see the general concensus is verging towards "XBITHACK is
> not the way to tell the server to parse a .html file" and I concede that in
> the middle to long term it would be a GOOD THING(tm) to remove this UNIXese
> kludge in favour of something that is:
> 

A solution to server-side includes should fall out of any work
we do to implement processing of <META>

As a first thought on the matter, I'd suggest the following,

   Before starting to send a document, a (file block size e.g.) chunk
   of the start of the html should be scanned for <META>, which
   is acted upon, before that data is parsed and/or sent,
   followed by the parsed and/or sent rest of the document.

   There must be a way to embed "server-side-includes" somewhere in
   the META tags. As well as a solution for the group XBITHACK e.g.

   <META NAME="X-Server-Side-Includes" CONTENT="1">
   <META NAME="X-Server-Side-Includes-Last-Modified" CONTENT="1">

   or (*)
   <META NAME="X-Server-Side-Includes-Last-Modified-Depends-On"
         CONTENT="myinclude.txt,/elsewhere/footnote.html"> 

   The server would see these and would be able to switch on the
   relevant parsing routines, and the client would be able to see
   that the document had been generated using this method.

   (*) could be used to inform the server that it should examine the
   age of myinclude.txt and  /elsewhere/footnote.html w.r.t the 
   document's age to determine the true Last-modified time. 

   Forcing all the META tags to appear in the first N bytes of a file
   would help reduce the impact of searching for them, and with examples
   such as (*), it could provide a means of specifying all the actions the
   server needs to perform for the document, so there would be no need
   to parse an entire document and/or preprocess any includes to determine
   their affect on HTTP headers.

robh