Re: tlug: HTTP headers q

[Adrian Havill <havill@example.com>]

On Thu, 17 Feb 2000, Frank Bennett (フランクべネット ) wrote:
> Looking at my still-untidy stuff around the headers, I found that AHA! 
> The header stuff was only being generated for the initial connection;
> after that, a cookie in the browser would be detected, and all of the
> header output would be avoided.  Something like: 
>     if {[lsearch -exact [cgi_cookie_list] clientid]==-1} {
>       puts "Content-type: content=\"text/html\"; charset=\"EUC-JP\""
>       puts "Pragma: content=\"no-cache\""
>       puts "Set-Cookie: clientid=$clientid"
>     }

The correct Pragma line is:

Pragma: no-cache

not

Pragma: content="no-cache"

Also, the Content-Type line should read:

Content-Type: text/html; charset=euc-jp

(no "content=", and the quotes aren't necessary. Case-insensitive, so
cApiTaLiZe as you wish). Apache is probably sensing that the Content-Type
is malformed, and replacing it.

This is a HTTP/1.0ism. For good measure and to be HTTP/1.1 cache and
browser friendly, you should also include the HTTP/1.1ism (since HTTP/1.0 
is depreciated):

Cache-Control: no-cache

HTTP/1.0 browsers (Netscape) will use the Pragma. HTTP/1.1 browsers (IE,
and libwww based browsers like Lynx and Amaya) will use the
Cache-Control. You can do neat things with Cache-Control, like
"Cache-Control: private", which means the proxy
shouldn't cache, but the browser may. This is actually what most CGIs that
use "GET" form posting methods want. Too bad HTTP/1.0 don't understand
it. Squid is getting close to HTTP/1.1 compliance... so if your Netscape's
come through a Squid proxy/cache, they'll grok (most of) 1.1.

> When I "fixed" things so that Content-type: and the Pragma: both output
> always, and added the empty line, I got what looks like *Apache's*
> Content-type: header (text/plain) as part of the text of the document when
> it is rendered.  What's Apache putting its finger into the works for?

The CGI 1.1 spec says it has to... the headers _are_ pre-interpreted,
because the HTTP/1.1 protocol is too complicated to just leave the headers
as-is. Apache will munge the headers to form a complete
request, since the client may have requested only a partial response or a
chunked response. (but the only library I know of that can do that
is libwww... and most software that uses it never takes advantage of the
full power of HTTP/1.1. Too bad, because that power was focused on caching
efficiency and speeding the WWW up) Also, your output to stdout is
buffered whether you like it or not, even if you use "nph-", for
compatibility with SSL and other things.

> I'm really just thrashing around with this at the moment.  What I want to
> do is fix the Content-type: header in the CGI and persuade Apache to just
> trust me and pass my headers through to the client verbatim.  I think that
> the FastCGI interface may be failing because I am not generating correct
> headers, but Apache won't leave well enough alone when I do.  Grrr.

I don't know is FastCGI is interfering or not. My advice is to first get
it working _without_ the FastCGI on plain CGI, then when you know it
works, transfer it over.

If you REALLY want to pass all the headers untouched, prefix your cgi
program with "nph-" (non parsed headers). However, the only headers that
CGI munges are "location" and "content-type" (and it doesn't really munge 
content-type... it changes changes the other headers it adds with the
output), so I don't think nph- will solve your problems.

I don't know if FastCGI supports nph- style CGIs, but Apache does.

> If anyone has read this far without their eyes glazing over ...  any
> suggestions?  Including (especially) texts I should read to better learn
> my way around Apache and CGI programming. 

The CGI/1.1 spec is <URL:http://hoohoo.ncsa.uiuc.edu/cgi/interface.html>
The HTTP/1.1 spec is RFC 2616.
--
Adrian HAVILL, Senior Software Engineer
Development Manager, TurboLinux Japan
PGP Key Fingerprint: D5B6 321C 0F82 117D EAC2 6D08 D942 FA38 7427 8195

--------------------------------------------------------------------
Next Nomikai Meeting: February 18 (Fri) 19:00 Tengu TokyoEkiMae
Next Technical Meeting:  March 11 (Sat) 13:00 Temple University Japan
* Topic: TBD
--------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan