perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <mma...@Doorways.org>
Subject RE: Handler attributes
Date Fri, 02 May 2003 05:02:16 GMT
> Can you please test the current modperl-2.0 cvs or alternatively
> apply this
> patch and let me know if this works now without the workaround?
> http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=105183931629250&w=2

Unfortunately I'm not building Apache or mod_perl right at the moment.  I
get sooooo frustrated building open-source / cross-platform packages on
Windows I'm in kind of avoidance mode right now.  You could probably talk
(or guilt) me into it but probably not before next week.  All that
downloading and fussing and breaking of furniture to consider.

Seems ungrateful I know...but I really have had a lot of serious pain
building stuff on Windows and my fuse has gotten short.  I went to build APR
or Apache just a few weeks ago and ran into some 'usual problem' (like I
would have to give M$ money for new versions of software or download 133Mb
of software over a 56K line or something like that) and just blew it off and
downloaded binaries.  Sigh.

So right now I'm running:

	Apache 		2.0.45
	mod_perl 		1.99_09-dev
	ActiveState Perl	build 804 (5.8.0)
	Windows		2000

all from binaries _including_ mod_perl which I got from wherever
perl.apache.org said to get it.

Yell at me some offline and I'll probably acquire the proverbial round tuit.

> > Yeah, I have app-specific code collecting the incoming data and
> then I spew
> > it at the end after seeing EOS.  I've tinkered some and can't reproduce
> > without
> > my code so I'm guessing it's my problem.  If I can reproduce w/o my code
> > I'll certainly pass along the example.
>
> I don't think we have a filter test that has no mod_perl handler
> that produces
> the response. If you can write one, that would be great! If you
> need help, ask.

After much fussing I finally determined that I got the problem when I
changed the content length during the filtration.  Yes, I have in fact read
the documentation, but of course the importance of the 'details' doesn't
always become apparent until after spending an hour or so wondering WTFO.

And of course my test scripts prior to the last posting did exactly what you
suggested:  they just passed input to output.  Which doesn't alter the
length, wouldn't ya know it.  Not that I wouldna thunk up the same test
myself, the obvious next step, just took another little bit to go on to a
simple handler that made the output length longer in passing like my real
handler does.

So when I demonstrated the problem to myself I went back to the doc and lo
and behold, there it was:

	HTTP request output filters should probably also unset the C-L header,
	if they change the size of the data that goes through it. (e.g. lc()
	filter shouldn't do it).

  		$filter->r->headers_out->unset('Content-Length');

A good candidate for boldface in the final documentation revision, but all
my own problem even so.

Note that my dummy PerlResponseHandler made it work OK where using the file
straight from Apache did not.  Well, whaddyaknow, my dummy
PerlResponseHandler never set the content length.  Apache probably does.
Mystery solved (I think).

mma


Mime
View raw message