META revisited

[Ben Laurie <be...@gonzo.ben.algroup.co.uk>]

A long, long time ago, I brought up the question of HTTP-EQUIV META tags. I
was told at the time that this is a client-side thing. However, this does not
appear to be the case. Firstly, the HTML 3.2 spec clearly says that this tag
should be used by servers, and secondly, Netscape at least do not process it at
the client end (as far as I can tell).

Standards-wise, this is somewhat unfortunate - should this really be in the
HTTP spec? Anyway, the question is, does anyone have any views? Should we
support this?

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Re: META revisited

[Marc Slemko <ma...@znep.com>]

On Mon, 24 Feb 1997, Rob Hartill wrote:

> On Mon, 24 Feb 1997, Ben Laurie wrote:
> 
> > A long, long time ago, I brought up the question of HTTP-EQUIV META tags. I
> > was told at the time that this is a client-side thing. However, this does not
> > appear to be the case. Firstly, the HTML 3.2 spec clearly says that this tag
> > should be used by servers, and secondly, Netscape at least do not process it at
> > the client end (as far as I can tell).
> > 
> > Standards-wise, this is somewhat unfortunate - should this really be in the
> > HTTP spec? Anyway, the question is, does anyone have any views? Should we
> > support this?
> 
> It makes far more sense for the CLIENT to parse the HTML for META
> since there's more spare cpu cycles on clients than servers, and the
> clients already have to parse the HTML anyway.

And I think this is an extremely good point.  The impact is trivial on the
client side and doing a lot of it on the server side can eliminate the
possibility of some possible performance enhancements that I'm thinking
about, some of them in connection with a threaded implementation; sure,
you have to scan some files anyway, but... 

OTOH, just because it makes more sense doesn't mean that is how it is/will
be done...

> 
> Should Apache support it ?, support - yes, as part of the core - no.
> 
> It's a trivial module to write (I have one for mod_perl), but it's
> definitely not for everyone.
> 
> 
> 

Re: META revisited

[Rob Hartill <ro...@imdb.com>]

On Mon, 24 Feb 1997, Ben Laurie wrote:

> A long, long time ago, I brought up the question of HTTP-EQUIV META tags. I
> was told at the time that this is a client-side thing. However, this does not
> appear to be the case. Firstly, the HTML 3.2 spec clearly says that this tag
> should be used by servers, and secondly, Netscape at least do not process it at
> the client end (as far as I can tell).
> 
> Standards-wise, this is somewhat unfortunate - should this really be in the
> HTTP spec? Anyway, the question is, does anyone have any views? Should we
> support this?

It makes far more sense for the CLIENT to parse the HTML for META
since there's more spare cpu cycles on clients than servers, and the
clients already have to parse the HTML anyway.

Should Apache support it ?, support - yes, as part of the core - no.

It's a trivial module to write (I have one for mod_perl), but it's
definitely not for everyone.