httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@osf.org>
Subject Re: function prototypes
Date Thu, 02 Jan 1997 01:07:26 GMT
Alexei Kosut <akosut@nueva.pvt.k12.ca.us> wrote:

> 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.

No, I really need to fix it so send_http_header is used instead.  
In general, I try to keep mod_perl as a thin glue layer.  mod_perl.c
has nothing to with sending the response other than invoking callbacks
to Perl subroutines, except when 'PerlSendHeader On'.  Then, the 
Perl*Handler callbacks are passed a request_rec * hidden in a Perl
variable.  Scripts then use this "blessed object" to go back inside the
server and call API functions (via "xsubs"), such as $r->send_http_header.
The glue code (Apache.xs) in most cases does nothing more than convert 
Perl data to C, call the C function counterpart, converting data back to 
Perl again.
With this thin layer in place, we can write modules entirely in Perl that 
can do just about everything a C module can.  One such module make things
appear as if we're in a CGI environment, including checks like OPT_EXECCGI,
etc., then runs your script.  This is the most popular Apache/Perl module, 
since most folks want to drop in existing Perl CGI scripts untouched, 
this is the only case where send_http_header won't do as is.

> 
> > 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.

'not trivial' was a poor choice of words.  It won't be that bad, but
keep in mind, you're talking to a Perl freak.  I try to only write C
code so I don't have to write C code (e.g. mod_perl :)  Writing parsing
code in C _really_ bugs me since it's so easy in Perl.

It will still be a little tricky since we don't get FILE *, and we could 
have any number of buffers come through with different parts of the content.
e.g.
print "Status: ";
print 200;
print "\n\n";
print "Content-type: ";
print "text/html";
print "\n\n";
...

Not that anyone would write code like this, but to give you the idea, the
script's STDOUT is hooked up to an sfio discipline, calling our write 
function everytime print is called.  State saving could get ugly, but I'll
read up more on sfio and see if it might have a clean way to help out.
Any other suggestions are welcome.

> 
> > > 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)

Apache is everywhere!!!

-Doug

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

Mime
View raw message