[ZPT] response.setHeader() best practice

Casey Duncan casey@zope.com
Tue, 09 Apr 2002 10:08:57 -0600


Yes I think you are right.

Ironically, I think this head parsing behavior is explicitly avoided 
though for performance reasons. A more "pythonic" (if non-standard) way 
was chosen using RESPONSE.setHeader.

It would be difficult I think for server-side interpretation of meta 
tags to not incur a large performance penalty. Due to the highly dynamic 
nature of most documents generated by Zope, it would be extremely 
difficult, or impossible, to predetermine the meta tags, and therefore 
the HTTP headers, before publication time.

Also, meta tags only handle the case of text/html, which although is 
arguably the predominant case handled by ZPT, still leaves all other 
content types using script-based header manipulation. So this is not a 
general solution.

This would, however, be a neat (and standard!) solution to the 
predominant case if you could implement it without a large performance hit.

-Casey

Alan Kennedy wrote:
>>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
> 
> 
> 
> 
> _______________________________________________
> ZPT mailing list
> ZPT@zope.org
> http://lists.zope.org/mailman/listinfo/zpt
> 
>