>
> 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
> 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