httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: Content-type negotiation: thoughts and code
Date Mon, 13 Mar 1995 21:26:39 GMT
   From: (Robert S. Thau)
   Date: Mon, 13 Mar 95 20:06:39 EST

   FWIW, the problem Brian was having here is that there's no way to get
   the server to process includes in a document which it believes to be
   of type text/x-html3.  (Brian, did I get that right?)

   Unfortunately, the only ways I can see out of this are somewhat ugly
   --- either generalizing XBITHACK so it will direct the server to
   process world-X files of *any* text/* MIME type, or add yet *another*
   magic MIME type (and also educate XBITHACK about text/x-html3).

Actually, there is another way --- to have suffixes carry attributes
as well as mime types, and to have server-parsedness be one of the
attributes which is stored, separately from the MIME type itself.
Then we could have stuff in mime.types like:

  text/html; level=2.0:                   html
  text/html; level=2.0, server_parsed=1:  shtml
  text/html; level=3.0:                   html3
  text/html; level=3.0, server_parsed=1:  shtml3

and have it all work, and all be configurable.  In fact, this would
also transparently allow includes to operate in other forms of
text-type stuff:

  text/plain; server_parsed=1:   stxt

(Note implicit change to the syntax of mime.types, to take the
presence of parameters on the mime types into account --- we can keep
this back-compatible by special casing the presence of only two tokens
on a line.  The same problem comes up with AddType directives, whose
args are also in the wrong order).

IMHO, that's the Right Thing, but it's rather more work than any of
the kludges I suggested.  In particular, it involves getting
http_mime.c rather further in bed with my new mime_db stuff, or the
equivalent, than it is right now.  (Right now, they're pretty much
separate; they only change my content-arb patch makes to http_mime.c
is to have it invoke functions which enter the client's Accept-foo
headers into the database).

If that doesn't bug anybody severely, I could try to do it next
weekend, along with my currently scheduled (though subject to change)
second pass over the content-arb code.


View raw message