You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@osf.org> on 1997/01/01 18:05:44 UTC

Re: function prototypes

robh@imdb.com (Rob Hartill) wrote:

> Alexei Kosut wrote:
> 
> >So why can't mod_perl use send_http_header(), like mod_cgi? 
> 
> err, it probably can and should.
> 
> >I see no
> >compelling reason why mod_perl needs to call basic_http_header(), and
> >I would need an explanation of this from a mod_perl person as to why
> >this is neccessary. Otherwise, I matinain a firm veto on adding it to
> >http_protocol.h.

Most Apache modules written in Perl will call $r->send_http_header.

The only time mod_perl itself uses basic_http_header is with
PerlSendHeader On

Why?  Most existing Perl CGI scripts have this line of code:
print "Content-type: text/html\n\n";
mod_cgi reads the script's output and stuffs headers into the 
outgoing headers table, before calling send_http_header, fine.
When a mod_perl script says 'print "something or other"', the 
data is pushed straight into rwrite()

If 'PerlSendHeader On' triggered send_http_header, headers are 
terminated with bputs("\015\012",fd), breaking
print "Content-type: text/html\n\n";

So, using basic_http_header was the easy way out.
I suppose the right thing to do is for mod_perl to read outgoing
data as mod_cgi does, but this would not be trivial with the 
existing API.  We have no FILE * to give scan_script_header_err().
I'll have to think about this more, in any case, mod_perl will
"do the right thing" before it becomes 1.00

> 
> good for you;  it's lucky someone's awake   %-)

I am not, last night was rough, yet I do not see stars, instead,
little camels flying around with multi-colored feathers 8-)

-Doug

Re: function prototypes

Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Wed, 1 Jan 1997, Doug MacEachern wrote:

> Most Apache modules written in Perl will call $r->send_http_header.
> 
> The only time mod_perl itself uses basic_http_header is with
> PerlSendHeader On
> 
> Why?  Most existing Perl CGI scripts have this line of code:
> print "Content-type: text/html\n\n";
> mod_cgi reads the script's output and stuffs headers into the 
> outgoing headers table, before calling send_http_header, fine.
> When a mod_perl script says 'print "something or other"', the 
> data is pushed straight into rwrite()

Hmm. This makes sense, but I'm concerned how it works with the
HTTP/1.1 stuff. Does it call set_keepalive in there? If it doesn't,
you don't get the Connection: close that's imperitive for HTTP/1.1
responses - or the chunked transfer-coding. But in that case, you end
up with worse problems, unless you duplicate send_http_header line for
line - and keep it up to date each time we update it. Not he approach
I reccomend.

> If 'PerlSendHeader On' triggered send_http_header, headers are 
> terminated with bputs("\015\012",fd), breaking
> print "Content-type: text/html\n\n";
> 
> So, using basic_http_header was the easy way out.
> I suppose the right thing to do is for mod_perl to read outgoing
> data as mod_cgi does, but this would not be trivial with the 
> existing API.  We have no FILE * to give scan_script_header_err().
> I'll have to think about this more, in any case, mod_perl will
> "do the right thing" before it becomes 1.00

It shouldn't be that hard to parse the output yourself. Given that
scripts probably aren't generating contining headers, and (I presume)
you know how long each line is, you should be able to simply scan for
a colon, split up the entry (a call to getword() would probably work),
and then call table_merge or set r->content_type or whatever (similar
things to what scan_script_header itself does), and then call
send_http_header when you get a blank line.

> > good for you;  it's lucky someone's awake   %-)
> 
> I am not, last night was rough, yet I do not see stars, instead,
> little camels flying around with multi-colored feathers 8-)

Hmm. Speaking of camels, did you notice that mod_perl is mentioned in
the new edition of the Camel Book? (page 370)

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/