[ZPT] response.setHeader() best practice

Tue, 9 Apr 2002 05:46:59 EST5EDT

> After all, setting HTTP Headers is not presentation but
> content. So its best placed in scripts.

I don't think it's a case of presentation vs content, I 
think it's a case of whether

A. Content meta-data belongs in the HTTP header

or

B. Content meta-data belongs in the HTTP body (i.e. the 
content).

In the case of the character encoding, it's an easy choice: 
it has to go in the HTTP header. If not, then you have a 
bootstrap problem: The character set encoding is in the 
content, so you have to read the content to find out what 
it is. But you can't decode the content until you know what 
character encoding it is......

Similar considerations apply to "content-type", "content-
length", etc. But let's focus on character encoding for the 
sake of argument.

Both HTTP *and* HTML allow you to specify character 
encoding, the former in the "Content-Type" HTTP header, and 
the latter in <meta> tags under the <head>.

However, the HTML <meta> element type, e.g., 

<meta http-equiv="Content-Type" content="text/html; 
charset=iso-8859-1"/>

was invented for the sole purpose of allowing the document 
author to communicate meta-data about the document *to the 
server*, so it still the servers responsibility to 
communicate the character encoding in the HTTP header.

The recommended server behaviour for web servers which are 
serving HTML content is for them to

1. Parse the content of HTML files (at least up to the end 
of the </head>).
2. Extract such meta information from the document
3. Set HTTP headers containing the document meta 
information, as specified by the document.

http://www.w3.org/TR/html401/struct/global.html#edef-META

So I think the real answer to this question lies in the 
server behaviour. 

1. Does the server which transmits the resources (currently 
only Zope) follow the steps outlined above?
2. Will all servers which contain implementations of 
ZPT/TAL follow the same guidelines?

If the answer to either of these questions is no, then I 
think the application developer has the following options.

1. Modify the server behaviour, through either 
reconfiguration or reprogramming, so that it does behave 
correctly.

2. Rely on the user-agent's (browser's) ability to guess 
the meta information.

3. Fall back to explicitly modifying the HTTP header, using 
script commands, during creation of the document.

I think. I might be wrong :-)

Alan Kennedy.

---------------------------------------------
This message was sent using WebMail by CyberGate.
http://www.gate.net/webmail