[ANNOUNCE] libapreq 1.0 released
(this is the package that provides Apache::Request and Apache::Cookie.) The URL http://httpd.apache.org/dist/httpd/libapreq-1.0.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JI/JIMW/libapreq-1.0.tar.gz size: 160944 bytes md5: 26b9c4c6667ce367cd28c46805bee2dd more information is at: http://httpd.apache.org/apreq/ the changes since 0.33: =item 1.0 - February 21, 2002 update to Apache Software License, Version 1.1 work around bug in Mozilla 0.9.7, which fails to send a required CRLF with each empty file field. [Joe Schaefer <[EMAIL PROTECTED]>] ignore empty cookie attributes; replace ap_getword calls with ap_getword_nulls for parsing "&" separator. brings the behavior of Apache::Cookie closer to that of CGI::Cookie, and hopefully improves the functionality of the C interface as well. [Maurice Aubrey] make apache_cookie.h c++ compatible [Simon Tamás <[EMAIL PROTECTED]>]
Re: What hapened to AxKit.com?
you can get to axkit.com at http://217.158.50.178/ you can read about matt's travails in getting it up and running again at his diary on use.perl.org. http://use.perl.org/~matts/journal jim
[ANNOUNCE] libapreq 0.33 released
(this is the package that provides Apache::Request and Apache::Cookie.) The URL http://httpd.apache.org/dist/httpd/libapreq-0.33.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JI/JIMW/libapreq-0.33.tar.gz size: 156885 bytes md5: 48c4c244db77c1855c6e4a6185e6ccdf more information is at: http://httpd.apache.org/apreq/ the changes since 0.31 (the last official full release): =item 0.33 - June 17, 2001 $r->upload can be set to another Apache::Upload instance [dougm] based on patch from Dave LaMacchia <[EMAIL PROTECTED]> =item 0.32 - April 4, 2001 fix $r->param( key => [ 0..9 ] ), convert to XS. [Joe Schaefer <[EMAIL PROTECTED]>] Thanks to Jody Biggs <[EMAIL PROTECTED]> for the spot and suggested fix. req->upload_hook, req->hook_data added. [David Welton <[EMAIL PROTECTED]>] upload->tempname, req->temp_dir; $upload->link(), $upload->tempname() added. [Joe Schaefer <[EMAIL PROTECTED]>] handle cookies containing "&", "=" in data. [Joe Schaefer <[EMAIL PROTECTED]>] $r->parms can be set to another Apache::Table instance [dougm] fix compile errors when PerlIO is used [dougm, Randy Kobes <[EMAIL PROTECTED]>] fix subclassing mechanism so the the value of an `r' or `_r' key can be a hash ref [dougm] fix win32 build (requires mod_perl later than 1.24_01) [Randy Kobes <[EMAIL PROTECTED]>] Handle cookies with names but no value [David Welton <[EMAIL PROTECTED]>] AIX compile fixes [Jens-Uwe Mager <[EMAIL PROTECTED]>] =item 0.31_03 - December 23, 2000 Apache::Request->instance [Matt Sergeant <[EMAIL PROTECTED]>] =item 0.31_02 - December 17, 2000 autoconf support [Tom Vaughan <[EMAIL PROTECTED]>] also parse r->args if content-type is multipart [Ville Skytt\xe4 <[EMAIL PROTECTED]>] deal properly with Apache::Cookie->new(key => undef) thanks to Matt Sergeant for the spot fix parsing of Content-type header to deal with charsets [Artem Chuprina <[EMAIL PROTECTED]>] fix nasty bug when connection is broken during file upload thanks to Jeff Baker for the spot multipart_buffer.[ch] renamed to apache_multipart_buffer.[ch] =item 0.31_01 - December 4, 2000 keep reusing same buffer when handling file uploads to prevent overzealous memory allocation [Yeasah Pell, Jim Winstead <[EMAIL PROTECTED]>] handle internet explorer for the macintosh bug that sends corrupt mime boundaries when image submit buttons are used in multipart/form-data forms [Yeasah Pell] fix uninitialized variable in ApacheRequest_parse_urlencoded [Yeasah Pell]
Re: cookies work for some browsers, not for others... ?
in general, your problem with some browsers that otherwise support cookies may be with issuing redirects and cookies on the same request, which has been known to trip up some browsers. the easy workaround is to use a refresh to do the redirection. fmt: w70: No such file or directory On Sat, Apr 28, 2001 at 02:44:29PM -0500, will trillich wrote: > ??? > what's that trailing zero for (or from), by the way? and that > "cf" that preceeds ??? chunked encoding. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 jim
Re: an unusual [job request] + taking mod_perl to the commercial world
On Fri, Apr 27, 2001 at 10:01:39AM -0700, Michael Lazzaro wrote: > At 12:00 PM 4/27/01 -0400, JR Mayberry wrote: > >there will be more dreams jobs like you described.. simple fact is, I > >couldn't name more then 3 companies in my area who use it, and I never > >expect to do work with it again. > > ... on the other hand, even as recently as one year ago, it was almost > impossible for our company (in southern california) to find mod_perl > programmers. Our last few job searches, tho, we've been able to find a > *very* good supply of applicants with mod_perl experience... it's no longer > been an issue. (Most mod_perl applicants seem to have come by their > experience from working on college campuses, BTW... which is another > interesting -- and valuable -- change. Not the fact that schools use it, > but the _volume_ of applicants who are now learning it there.) well, i suspect a lot of those candidates actually surfaced as other idealab-backed companies either tanked or shifted direction. the death of etoys freed up a number of mod_perl-savvy developers. :) (in all seriousness, though, idealab and many of the companies it has spawned is a mod_perl-friendly place.) and my experience is that you don't need to hire mod_perl experts -- specific skillsets are some distance down on the list of things i look at in hiring someone. given a good framework to develop in, and a good programmer who is willing to learn, mod_perl skills will bloom. but, outside of the linux companies and covalent, i don't know where one would look for a job just developing mod_perl itself. jim
Re: Dynamic httpd.conf file using mod_perl...
On Mon, Apr 16, 2001 at 07:37:32PM -0400, Brian wrote: > > > it seems to me you're conflating your goal and your means of achieving > > it. > > I don't think I'm conflating the goal and the means. At least I don't see > how I am well, perhaps that wasn't the best way to put it. > > this is certainly possible by generating your configuration files > > using a perl script, outside of using mod_perl. > > Aaah, but you see that would create a bunch of configuration files or make > one huge configuration file. My method would eliminate all but one > configuration file (httpd.conf) and use our billing database to create the > configuration files. That way when a client is deactivated in the DB it's > automatically deactivated in apache the next time it's HUP'ed. Yeah, I > could write a separate perl script to go in, find the line that says > "Include /www/conf/viraul/domain.conf" and then pound it out and restart the > server. I can also write a perl script to create all the config files for > me. But why not do both in the config file if possible? and the suggestion perrin made would have basically the same result. your configuration file would be a template, basically, that was expanded into the real configuration file that is then read by the apache process. it is very close to what you are doing, without introducing the vagaries of getting mod_perl and mod_rewrite to cooperate. you would have to do a "run config template expander && HUP" instead of just doing a HUP of the apache parent process, but that doesn't seem like a big deal to me. > It's all written, only problem is the mod_rewrite directives. Any ideas on > how to do them in a directive? Thanks in advance. nope. jim
Re: Dynamic httpd.conf file using mod_perl...
On Mon, Apr 16, 2001 at 07:12:23PM -0400, Brian wrote: > > It might be easier and more bulletproof to build the conf file > > off-line with > > a simple perl script and a templating tool. We did this with Template > > Toolkit and it worked well. > > - Perrin > > That would be fine and dandy, but it's not exactly what I'm going after. it seems to me you're conflating your goal and your means of achieving it. > Currently if I want to make a change to all of our clients I have to go > through and edit every config file (I have a .conf file for each domain and > then use an Include in the httpd.conf). Using the mod_perl way I can change > it once in the httpd.conf file, restart apache, and the change will take > place for all the domains that are affected by the code. > Know what I mean? this is certainly possible by generating your configuration files using a perl script, outside of using mod_perl. jim
Re: [Very OT] Politically Correct-ness (was: RE: [OT] ApacheCon BOF)
On Wed, Mar 21, 2001 at 08:14:53AM -0800, Paul wrote: > --- Nick Tonkin <[EMAIL PROTECTED]> wrote: > > Personally I find the very name Apache a little uncomfortabl. I get > > the joke about it being a patchy server (although now the ratio of > > original NCSA code to `new' code is so miniscule as to invalidate the > > patch theme anyway, imho), but the relevance of an http server to the > > Apache nation escapes me (and the symbolizing of the Apache nation > > with a feather strikes me as stereotypical at best). > >Let's be careful here, people. >It was a linguistics joke, not an ethnic one. >No 'relevance' was ever intended. i want this thread to die as much as everyone else, but i feel compelled to correct history a bit -- the "a patchy server" story is apocryphal. the name came before the pun. http://www.linux-mag.com/2000-04/behlendorf_02.html (but, really, let this part of the thread die, please.) another note to throw out there -- o'reilly claims trademarks on the camel/perl association and the mod_perl/eagle association, so someone will either need to get permission from them to print a shirt perpetuating those associations, or come up with a different idea. search the list archives for this same discussion from last year. jim
libapreq-0.31_03
The uploaded file libapreq-0.31_03.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JI/JIMW/libapreq-0.31_03.tar.gz size: 151839 bytes md5: c23cb069e42643e505d4043f0eef4b9f it is also available at: http://httpd.apache.org/dist/libapreq-0.31_03.tar.gz more information is at: http://httpd.apache.org/apreq/ the plan is to release this code as 0.32 early in the new year if there are no major problems spotted with this test release. if someone sends patches to compile libapreq on win32 with the latest mod_perl cvs, those would gladly be incorporated. :) the changes since 0.31: =item 0.31_03 - December 23, 2000 Apache::Request->instance [Matt Sergeant <[EMAIL PROTECTED]>] =item 0.31_02 - December 17, 2000 autoconf support [Tom Vaughan <[EMAIL PROTECTED]>] also parse r->args if content-type is multipart [Ville Skyttä <[EMAIL PROTECTED]>] deal properly with Apache::Cookie->new(key => undef) thanks to Matt Sergeant for the spot fix parsing of Content-type header to deal with charsets [Artem Chuprina <[EMAIL PROTECTED]>] fix nasty bug when connection is broken during file upload thanks to Jeff Baker for the spot multipart_buffer.[ch] renamed to apache_multipart_buffer.[ch] =item 0.31_01 - December 4, 2000 keep reusing same buffer when handling file uploads to prevent overzealous memory allocation [Yeasah Pell, Jim Winstead <[EMAIL PROTECTED]>] handle internet explorer for the macintosh bug that sends corrupt mime boundaries when image submit buttons are used in multipart/form-data forms [Yeasah Pell] fix uninitialized variable in ApacheRequest_parse_urlencoded [Yeasah Pell]
Re: RFC: Apache::FileMan
On Dec 18, George Sanderson wrote: > At 01:40 PM 12/18/00 -0800, you wrote: > >you should take a look at the interface of the file management of > >some of the free webspace providers. > > I have looked at some of these. They do not look and feel like a file > manager. They tend to be fragmented and wordy. a matter of taste, of course. it also depends on your target audience. most of the free webspace providers are oriented towards the lower-end of net-savviness, so things tend to be verbose. but they also tend to have done actual usability testing, so i think they're worth looking at to at least steal ideas from. :) (as an example, i ran across one site that used javascript to pop up a "uploading...please wait" window when you submitted a form to do a file upload, and then put javascript on the page sent in response to the upload to close that window. a very slick solution to the problem that most browser don't provide any meaningful feedback for http file uploads.) > >i haven't really looked at the Apache::FileMan module, but the > >biggest thing i would suggest is using something like the Template > >Toolkit to move the html pages into templates. > > I am not there yet. FileMan does not require any client software and it is > independent of the file content. It just doesn't care what is in a files > or directory. i didn't mean to suggest that, i meant you might want to move towards getting rid of all the 'print "blah blah blah"', in your code and use something like Template Toolkit (or HTML::Template, or any of the others). http://www.template-toolkit.org/tpc4/paper.html#cgi (well, the whole document, really) is a good place to read about what i'm talking about. (a browser-based html template editor, which is what i gather you took me to mean, is also certainly possible. been there, done that, wouldn't recommend it. :) > >(personally, i've moved on to using dav (http://www.webdav.org/) > >for most of my web-based file management needs.) > > I know very little about WebDAV. I looked at the site and found the DAV > concepts interesting. Perhaps you could point me to a demo or more > information about how the requirements are implemented. WebDAV appears to > integrate the CASE information within the XML documents themselves. well, webdav is an extension to http that allows you to "put", "delete", "move", "copy", etc. the "webfolders" functionality bundled with internet explorer on windows supports this. i've been hacking together a very simple gtk-based file manager that supports it, too (http://trainedmonkey.com/torem). http://www.mydocsonline.com/ is an example of a service that provides free space that is dav-accessible, if you just want to play around with some of the clients and not spend time setting up your own dav server. jim
Re: Unset PerlAuthenHandler (I wish)
On Dec 18, Jeff Sheffield wrote: > Ok, essentially I want all but one directory on the > server to be password protected. > I want 1 directory to have the "I forgot my password" > functionality. > > I am using Mason. > and setting SetHandler default-handler has undesired results. > i.e. mason files do not get parsed. > Essentially I want to do this. > Unset PerlAuthenHandler well, not really, because that would still fail, since you "require valid-user". you can do it with this: order allow,deny allow from all satisfy any check the apache docs (http://httpd.apache.org/docs/) for more on 'require' and 'satisfy'. jim
Re: Mod_perl vs mod_php
On Dec 13, Roger Espel Llima wrote: > So, does anyone know what PHP does? Does it parse the mixture of > PHP and HTML every time? Does it keep a cache? Does it limit the > size of this cache (which Apache::Registry doesn't)?. How big does > a typical Apache/PHP process get? both php3 and php4 reparse every file, out of the box. php3 parses and executes simultaneously, php4 is more like perl and has a two-step compile-and-execute. the php4 runtime is designed to allow plugins to do caching of compiled scripts. bwcache (http://bwcache.bware.it/) is one such plugin, and zend cache (http://www.zend.com/zend/products.php#cache) is another that is supposed to be released soon. i don't know about a 'typical' apache/php process, but the httpd processes on www.php.net run at around seven megs (vsz -- rss is around 3-5 megs). but that's a totally meaningless number, of course, since it doesn't take into account any shared pages across those processes. (for what its worth, www.php.net runs on a dual p3/650 with 512M of ram and does about four million page views and 300 gigs of raw traffic a month. i would consider that an atypical setup -- most users of php are the people who host at the scads of shared hosting companies that offer php support.) for comparisons of php and mod_perl, i would focus on the things you can do in mod_perl that you simply can't in perl (handlers for phases other than content-handling, for example). mod_perl gives you a lot more rope to do cool things and to hang yourself with. (the former is why most of us are here, the latter is why there aren't scads of shared hosting companies that offer mod_perl.) jim
Re: load average: 24.07, 14.76, 9.20
On Dec 17, Philip Mak wrote: > I don't really know what to do to fix this, other than typing > /sbin/reboot. Looking at "top" doesn't show any very big processes, so I > suspect it might be being caused by a large number of small processes. try running vmstat and seeing if there are a lot of process blocked. (the second column in vmstat on linux and freebsd.) then see how many httpd process you have running. then see what files they are serving and to who. (mod_status is useful for that last one.) you may find that you're pushing a lot of large files to people on slow connections (like international ones), which is causing the number of apache servers to pile up and push you into swap. once that happens, it is usually a spiral of doom from there. and of course, http://perl.apache.org/guide/performance.html is your friend. jim
Re: custom directives done using filters
On Dec 09, Robin Berjon wrote: > I feel bad insisting because I know most of you are probably at least as > busy as I am. I posted a message a few days ago > (http://www.geocrawler.com/lists/3/Web/182/200/4787953/) and didn't get a > single answer. I understand if you don't want to read it as it's fairly > long. Basically, I'm trying to some up with a way to implement custom > directives by applying Perl source filters in httpd.conf, but for some > reason it isn't working. the configuration file is actually read and processed by apache, so i don't see how perl source filters could be applied to it. jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Slow Mailing List
On Dec 08, Gunther Birznieks wrote: > Now that traffic has increased on this list, I don't know if this is an > illusion but it seems to take a really long time between the time I post a > message and the mod_perl mailing list gets it back to me. the machine that handles mail for all of the apache.org mailing lists is currently a bit overloaded during peak hours. there's work afoot to replace it with a beefier, more finely tuned, and dedicated-for-mail-handling machine within the next couple of weeks (being conservative -- it could happen sooner). in the meantime, be patient. :) jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Dec 05, Greg Cope wrote: > > But, you all know that php pretty much takes over. Why? For two reasons: > > 1) initial corporate pushing (press/ads) > > 2) once well known, the word of the mouth does the rest. > > Well go back 2 / 2 1/2 years and PHP was little known. what is even funnier is that if you go back that far and look at the php mailing lists back then, you'll find the exact same conversations. :) how did php become so popular? so many hosting companies offered it as part of their hosting. fortunately for php, it targets a bit more of a niche (generating dynamic content) than mod_perl does (writing apache modules in perl) so offering it as part of a hosting package on shared servers is quite a bit easier. (of course, this only addresses scaling to a breadth of users, not scaling into the enterprise area. that just requires real marketing and hype.) jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 1.24 for Apache 1.3.14 patch
On Nov 30, Doran L. Barton wrote: > [ patch to handle 1.3.14 version string ] > > Think 1.25 will have this fixed? its already fixed in 1.24_01(*), so yes. jim (*) http://perl.apache.org/dist/mod_perl-1.24_01.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed -> mod_perl Module for HTML Compression
On Nov 30, Geoffrey Young wrote: > I was basing that on discussions on the mod_gzip list and the following > (from the mod_gzip code) > > * 5. Many browsers ( such as Netscape 4.75 for UNIX ) are unable > *to handle Content-encoding only for specific kinds of HTML > *transactions such as Style Sheets even though the browser > *says it is HTTP 1.1 compliant and is suppying the standard > *'Accept-encoding: gzip' field. According to the IETF > *specifications any user-agent that says it can accept > *encodings should be able to do so for all types of HTML > *transactions but this is simply not the current reality. > *Some will, some won't... even if they say they can. > > I don't have any first hand experience with it, though... i don't have any first-hand experience with it either (and don't doubt at all that there are browser bugs in the implementations), but the language of that comment is atrocious. there's no such thing as an "html transaction". all the http/1.1 rfc (2616) has to say on the matter is that if the browser sends an accept-encoding header that lists an encoding type (such as gzip) with a non-zero q-value, the server may send the response using that content-encoding. it doesn't matter what type of data is being served (the server could gzip gif images if it really wanted). nothing beats just having a reasonable test environment to be able to test the major browsers against your site. with something like vmware, you can even use a single box to act as most of your platforms. (you could probably even do better by having a macintosh and using one of the virtual-intel-pc applications available for it.) jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ libapreq ] desesperatly need of .32 or .33
On Nov 22, Joe Schaefer wrote: > But before anyone bites off more than they can chew, perhaps some > discussion of the current bugs and future needs for libapreq should > be aired out. the issues i know of: * memory bloat from multipart buffer code (but there's your patch and the one i've sent the list that both address this) * workaround to handle multipart/form-data data sent from internet explorer on the macintosh from forms with image submits which are sent with an incorrectly terminated boundary string, if i remember the details correctly. the patch i've sent to the list addresses this, too. * in ApacheRequest_parse_urlencoded, 'data' isn't initialized properly, which can result in processes spinning out of control. (fixed in the patch i've sent before, but a trivial fix anyway.) * the content-type tests don't handle encodings quite right (patch: http://www.mail-archive.com/modperl@apache.org/msg08188.html) * i seem to remember there being a bug in the cookie handling that choked when an undefined value was passed in. easy to fix once the details are dug up. (this may actually have been something in mod_perl itself that i'm misremembering.) * win32 patches? things that could be added to libapreq: * intelligent cross-request-phase handling of posted form data, a la RequestNotes. (it looks to me like the data is already allocated out of the per-request pool, so it should just be a matter of stuffing the data in the real request rec instead of the Apache::Request object so the next Apache::Request object can see the data.) * $apr->parms documented (possibly with a better name, as doug has suggested) * someone has suggested that Apache::Cookie->new should check the first argument to make sure it is passed the right thing. (http://www.mail-archive.com/modperl@apache.org/msg05151.html) * the whole thing just folded into mod_perl since it is, in my opinion, indispensable. :) there's also the few things in the ToDo file in the libapreq distribution. jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A really really weird use for subrequests...
On Oct 04, Luis 'Champs' de Carvalho wrote: > Can i make the mod_proxy redirect using a sub-request, and still > have the contents (and headers, and everything else) to let apache handle > the response phase ? no. > If not, how can i do this weird thing? take a look at Apache::RewritingProxy. http://search.cpan.org/search?dist=Apache-RewritingProxy jim
Re: open ">-" does not work
On Sep 29, Doug MacEachern wrote: > On Fri, 29 Sep 2000, Vsevolod Ilyushchenko wrote: > > Yes, I know. I just want to see how far I can go with the "open". > > Besides, according to the author of the script (it's for the analog web > > log analyzer), using open is more secure. > > i've never heard that before, how is it more secure? more efficient > maybe, but doubt that its more secure. probably a reference to the fact that you have to escape the arguments used in something like $foo = `cat $bar` because it will go through /bin/sh, but you can avoid that by using open/fork/exec (or the three-argument open in perl 5.6). jim
Re: flock under win32
On Sep 24, Gunther Birznieks wrote: > The PerlCookbook seemed to indicate that mkdir is an atomic operation (both > checks if the directory exists and creates it if it does not), so a locking > mechanism based on mkdir would take care of this issue > presumably. Removing the lock is a matter of removing the directory. > > However, (maybe this is right ... i dont have it here with me), the > PerlCookbook was saying this within the context of an NFS locking mechanism > I think. So, if mkdir is not truly atomic under Perl's implementation for > Win32 then that would screw that over. Would anyone here know off the top > of their head? be careful, mkdir isn't really atomic under nfs. jim
Re: HTML Template Comparison Sheet ETA
On Sep 04, brian moseley wrote: > On Mon, 4 Sep 2000, Perrin Harkins wrote: > > > [% FOREACH thing = list %] > > [% thing.name %] > > [% END %] > > what's the value? you have to write a parser and then > interpret the instructions. that's what eval() is for! and > your syntax is no prettier or easier to understand than the > perl. an interesting design constraint to introduce is allowing arbitrary (read: non-trusted) users to use the template markup. sometimes you can't just allow arbitrary perl to be embedded. and another thing i like to cater to is allowing the templates to be reasonably edited in common wysiwyg editors, which pushed me towards the ASP-style tag delimiters. paul's use of the class syntax is an interesting alternative to that. jim
Re: [OT] DNS question (slightly mod_perl related...)
On Aug 31, David Hodgkinson wrote: > martin langhoff <[EMAIL PROTECTED]> writes: > > > Is it possible to tell BIND to catch *.domain.com and answer the same > > ip? > > Plan A: Generate the zone files from the database. > > Plan B: Use the beta of Bind 9 which, I believe, has database bindings > promised. plan c: use a wildcard record and move on to real problems. :) jim
Re: Apache::Request growing httpd
On Aug 28, Dave Thomas wrote:
> I applied the patch from the archives but the httpd child process is
> still
> growing by the size of the file. Is that normal, or is there an update
> to the patch that Jim Winstead placed out there
>
> The system that I am running on is:
> SunOS 5.6 on a sparc Ultra-1
>
> Thanks in advance for any help that can be provided.
i haven't tested on solaris, but attached is the latest version of
our patch. this may or may not be identical to the most recent
version that was last posted here.
you might also want to triple-check that you're using the patched
version of libapreq. i know i've forgotten to "make install" or do
a restart after recompiling more times than i've got fingers to
count on. :)
there's also another patch to solve this problem. i haven't tested
it (and don't know if handles some of the problems that i'm sure
our patch does, like work around a bug in internet explorer on the
macintosh), but you might want to try that out, too.
(this patch is being used on production servers run by homepage.com
that power a whole bunch of quite busy personal-publishing sites,
and has been quite heavily exercised by our qa team. while it
avoids the memory-bloat problem, it also doesn't ever spin out of
control, which is what we found the 'stock' libapreq to do. we run
mostly freebsd in production, and some linux, so it has seen the
most testing on those.)
jim
diff -ruN libapreq-0.31/c/apache_request.c libapreq-0.31-new/c/apache_request.c
--- libapreq-0.31/c/apache_request.cFri Jul 2 18:00:17 1999
+++ libapreq-0.31-new/c/apache_request.cTue Jul 11 17:23:58 2000
@@ -293,7 +293,7 @@
int rc = OK;
if (r->method_number == M_POST) {
- const char *data, *type;
+ const char *data = NULL, *type;
type = ap_table_get(r->headers_in, "Content-Type");
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req->parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req->parms, param, value);
continue;
}
ap_table_add(req->parms, param, filename);
@@ -424,7 +425,7 @@
upload->filename = ap_pstrdup(req->r->pool, filename);
upload->name = ap_pstrdup(req->r->pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, &blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload->size += fwrite(buff, 1, blen, upload->fp);
}
diff -ruN libapreq-0.31/c/multipart_buffer.c libapreq-0.31-new/c/multipart_buffer.c
--- libapreq-0.31/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31-new/c/multipart_buffer.c Tue Jul 11 17:38:11 2000
@@ -57,271 +57,280 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first && little >= littleend) {
-return big;
-}
-if (bigend - big < littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen < len ? needlen : len) == 0 &&
Re: recursion in Apache::Constants::AUTOLOAD?
On Aug 15, Doug MacEachern wrote: > On Mon, 26 Jun 2000, Jim Winstead wrote: > > > We were seeing some servers spin out of control (allocating memory > > slowly) in Apace::Constants::AUTOLOAD (which apparently has been > > reported in the mailing list before). > > > > The attached patch fixes the problems for us. Could someone who > > understands what is going on here shed some light? > > ouch, how did you trigger this problem? i don't see how that could > happen Apache::Constants::__AUTOLOAD should always be defined inside > httpd. does this version of your patch prevent it? good question. i have no idea what triggered it. and since our patch seems to have cleared up the problem for us (which i think we only ever saw on production servers), i'm reluctant to try a new one. perhaps it is related to this old problem: http://marc.theaimsgroup.com/?l=apache-modperl&m=94528502827088&w=2 jim
Re: PERL 5.6 & Mod_perl: How stable is it?
On Jul 05, William Deegan wrote: > I've seen quite a few messages around problems with it? > Is it ready for production? Does more than a million pageviews a day count as production? (I don't know offhand how much more than a million.) :) (FreeBSD 3.4, Apache 1.3.12, Perl 5.6.0, mod_perl 1.24.) Jim
recursion in Apache::Constants::AUTOLOAD?
We were seeing some servers spin out of control (allocating memory
slowly) in Apace::Constants::AUTOLOAD (which apparently has been
reported in the mailing list before).
The attached patch fixes the problems for us. Could someone who
understands what is going on here shed some light?
Jim
diff -ruN mod_perl-1.24/Constants/Constants.pm mod_perl-1.24-new/Constants/Constants.pm
--- mod_perl-1.24/Constants/Constants.pmFri Mar 3 12:20:30 2000
+++ mod_perl-1.24-new/Constants/Constants.pmSun Jun 25 15:40:41 2000
@@ -14,13 +14,9 @@
*import = \&Exporter::import;
}
-if ($ENV{MOD_PERL}) {
-#outside of mod_perl this will recurse looking for __AUTOLOAD, grr
-*AUTOLOAD = sub {
- #why must we stringify first???
- __AUTOLOAD() if "$Apache::Constants::AUTOLOAD";
- goto &$Apache::Constants::AUTOLOAD;
-};
+sub AUTOLOAD
+{
+return __AUTOLOAD() unless $AUTOLOAD =~ /__AUTOLOAD$/;
}
my %ConstNameCache = ();
diff -ruN mod_perl-1.24/src/modules/perl/Constants.xs
mod_perl-1.24-new/src/modules/perl/Constants.xs
--- mod_perl-1.24/src/modules/perl/Constants.xs Wed Mar 29 16:05:32 2000
+++ mod_perl-1.24-new/src/modules/perl/Constants.xs Sun Jun 25 17:09:42 2000
@@ -938,7 +938,7 @@
#endif
-void
+double
__AUTOLOAD()
PREINIT:
@@ -956,6 +956,9 @@
croak("Your vendor has not defined Apache::Constants macro `%s'", name);
else
my_newCONSTSUB(stash, name, newSViv(val));
+RETVAL = val;
+OUTPUT:
+RETVAL
const char *
SERVER_VERSION()
modperl@apache.org
So I finally tracked down the real cause of the crash (someone was
scribbling past the end of a buffer as suspected, but my last "fix"
just fixed the caller, not the culprit).
Attached is a patch that fixes that, and also uses the whole buffer
it allocates from the pool instead of always only using FILLUNIT
bytes of it.
(BTW, although I've been helping get this nailed down, I'm not the
primary author of this patch. The credit for the real heavy-lifting
goes to Yeasah Pell.)
This appears to sort out the problems to me.
Jim
diff -ur libapreq-0.31-orig/c/apache_request.c libapreq-0.31/c/apache_request.c
--- libapreq-0.31-orig/c/apache_request.c Fri Jul 2 18:00:17 1999
+++ libapreq-0.31/c/apache_request.cMon Jun 26 11:49:31 2000
@@ -293,7 +293,7 @@
int rc = OK;
if (r->method_number == M_POST) {
- const char *data, *type;
+ const char *data = NULL, *type;
type = ap_table_get(r->headers_in, "Content-Type");
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req->parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req->parms, param, value);
continue;
}
ap_table_add(req->parms, param, filename);
@@ -424,7 +425,7 @@
upload->filename = ap_pstrdup(req->r->pool, filename);
upload->name = ap_pstrdup(req->r->pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, &blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload->size += fwrite(buff, 1, blen, upload->fp);
}
diff -ur libapreq-0.31-orig/c/multipart_buffer.c libapreq-0.31/c/multipart_buffer.c
--- libapreq-0.31-orig/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31/c/multipart_buffer.c Mon Jun 26 11:49:15 2000
@@ -57,271 +57,284 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first && little >= littleend) {
-return big;
-}
-if (bigend - big < littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen < len ? needlen : len) == 0 &&
+(partial || len >= needlen))
+ break;
+
+ /* next character */
+ ptr++; len--;
}
-bigend -= littleend - little++;
-while (big <= bigend) {
- if (*big++ != first) {
- continue;
- }
- for (x=big,s=little; s < littleend; /**/ ) {
- if (*s++ != *x++) {
- s--;
- break;
- }
- }
- if (s >= littleend) {
- return big-1;
- }
+
+ return ptr;
+}
+
+/*
+ fill up the buffer with client data.
+ returns number of bytes added to buffer.
+*/
+int fill_buffer(multipart_buffer *self)
+{
+ int bytes_to_read, actual_read = 0;
+
+ /* shift the existing data if necessary */
+ if(self->bytes_in_buffer > 0 && self->buf_begin != self->buffer)
+memmove(self->buffer, self->buf_begin, self->bytes_in_buffer);
+ self->buf_begin = self->buffer;
+
+ /* calculate the free space in the buffer */
+ bytes_to_read = self->bufsize - self->bytes_in_buffer;
+
+ /* read the required number of bytes */
+ if(bytes_to_read > 0)
+{
+ char
Re: Apache::Request and memory
Okay, I think I tracked this down to a one-byte buffer overflow.
Try the attached patch to see if that fixes it (it fixes things
in my testing).
Unfortunately, the overflow seemed to sneak through with no problems
on FreeBSD, and on Linux if you compile with -g.
Jim
On Jun 24, dorian wrote:
> breaks for me too. null byte issue maybe? i don't know. i can't write c. :)
>
> .djt
diff -ur libapreq-0.31-orig/c/apache_request.c libapreq-0.31/c/apache_request.c
--- libapreq-0.31-orig/c/apache_request.c Fri Jul 2 18:00:17 1999
+++ libapreq-0.31/c/apache_request.cSat Jun 24 16:23:06 2000
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req->parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req->parms, param, value);
continue;
}
ap_table_add(req->parms, param, filename);
@@ -424,7 +425,7 @@
upload->filename = ap_pstrdup(req->r->pool, filename);
upload->name = ap_pstrdup(req->r->pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, &blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload->size += fwrite(buff, 1, blen, upload->fp);
}
diff -ur libapreq-0.31-orig/c/multipart_buffer.c libapreq-0.31/c/multipart_buffer.c
--- libapreq-0.31-orig/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31/c/multipart_buffer.c Sat Jun 24 16:23:25 2000
@@ -57,271 +57,283 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first && little >= littleend) {
-return big;
-}
-if (bigend - big < littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen < len ? needlen : len) == 0 &&
+(partial || len >= needlen))
+ break;
+
+ /* next character */
+ ptr++; len--;
}
-bigend -= littleend - little++;
-while (big <= bigend) {
- if (*big++ != first) {
- continue;
- }
- for (x=big,s=little; s < littleend; /**/ ) {
- if (*s++ != *x++) {
- s--;
- break;
- }
- }
- if (s >= littleend) {
- return big-1;
- }
+
+ return ptr;
+}
+
+/*
+ fill up the buffer with client data.
+ returns number of bytes added to buffer.
+*/
+int fill_buffer(multipart_buffer *self)
+{
+ int bytes_to_read, actual_read = 0;
+
+ /* shift the existing data if necessary */
+ if(self->bytes_in_buffer > 0 && self->buf_begin != self->buffer)
+memmove(self->buffer, self->buf_begin, self->bytes_in_buffer);
+ self->buf_begin = self->buffer;
+
+ /* calculate the free space in the buffer */
+ bytes_to_read = FILLUNIT - self->bytes_in_buffer - 1;
+
+ /* read the required number of bytes */
+ if(bytes_to_read > 0)
+{
+ char *buf = self->buffer + self->bytes_in_buffer;
+ ap_hard_timeout("[libapreq] multipart_buffer.c:fill_buffer", self->r);
+ actual_read = ap_get_client_block(self->r, buf, bytes_to_read);
+ ap_kill_timeout(self->r);
+
+ /* update the buffer length */
+ if(actual_read > 0)
+ self->bytes_in_buffer += actual_read;
}
-return NULL;
Re: maintaing global variable in PerlLogHandler
Attached is an updated version of the patch that should apply
to Apache 1.3.12 cleanly.
I don't know if anyone's ported the patch to 2.0. I'm not sure how
significantly, if at all, mod_usertrack has changed for 2.0.
(This has an additional feature, CookieDomainEnv, which is less
documented and probably not as completely useful as it could be.)
Jim
On Jun 24, Greg Cope wrote:
> Jim Winstead wrote:
> >
> > On Jun 23, Jim Sproull wrote:
> > > This all works fine. However, the get_sessionid and set_sessionid are
> > > using a dbm file, which is locked and unlocked during each request. (I
> > > know, I know). Obviously, this is a lot more load that is necessary. I
> > > tried using a simple global variable (defined before the handler), but this
> > > was unreliable as it was set differently for each request. No doubt due to
> > > different processes handling each request. Can anyone suggest a better way
> > > of handling this globablly accessed data? Thanks.
> >
> > If you search the new-httpd list, you should be able to find a
> > patch I posted to mod_usertrack (quite some time ago) that in
> > addition to adding a configuration option (to set the cookie's
> > domain or something like that), makes mod_usertrack create two
> > additional notes -- "out-cookie" and "in-cookie" which are set to
> > the value of its session cookie depending on whether it is outgoing
> > (being set) or incoming (subsequent requests).
>
> This is just what I've been after (the domain and cookie set checking) -
> thanks.
>
> Has anyone an issues with using this apache module with mod_perl. I
> need to track users via cookies on a site that is 1/2 html and half
> mod_perl - hence this offers an ideal solution for cookie tracking HTML
> pages via an UID.
>
> Jim , all the patches that I've found from you in archives appear to be
> incomplete, I've tried fixing one but to little avail (my C is very very
> basic).
>
> Could you post or send me the patch - would be very much appreciated!
>
> Also does anyone know if anyone is working on an Apache 2.0 version ?
>
> Greg Cope
>
> >
> > With that, it is very easy to know when the cookie is new, and if
> > you log the two fields seperately, you can easily calculate the
> > number of your visitors who have cookies disabled (or only make
> > a single request to the webserver).
> >
> > Jim
>
diff -ur apache_1.3.12-orig/htdocs/manual/mod/mod_usertrack.html
apache_1.3.12/htdocs/manual/mod/mod_usertrack.html
--- apache_1.3.12-orig/htdocs/manual/mod/mod_usertrack.html Wed Feb 23 15:11:39
2000
+++ apache_1.3.12/htdocs/manual/mod/mod_usertrack.html Sat Jun 24 13:14:14 2000
@@ -45,6 +45,13 @@
CustomLog logs/clickstream "%{cookie}n %r %t"
++
+In Apache 1.3.13 or later, the cookie can also be logged whether
+it is outgoing (being set for the first time) or incoming, with
+%{out-cookie}n and %{in-cookie}n, respectively,
+in the log format.
+
+
For backward compatibility the configurable log module implements the
old CookieLog directive, but this should be upgraded to the
above CustomLog directive.
@@ -52,12 +59,90 @@
Directives
+CookieDomain
+CookieDomainEnv
CookieExpires
CookieName
CookieTracking
+
+CookieDomain
+Syntax: CookieDomain token
+
+Default: None
+
+Context: server config, virtual host, directory, .htaccess
+Status: optional
+Module: mod_usertrack
+
+
+This directive allows you to change the domain of the cookie this module
+uses for its tracking purposes. By default the cookie is sent with
+no domain, which tells the browser to only return the cookie to the
+hostname from which it received the cookie.
+
+
+
+For example, by setting the domain to ".apache.org", the same cookie
+will be used to track users across http://www.apache.org, dev.apache.org,
+and all of the other subdomains within the apache.org domain.
+
+
+
+The domain you specify must be the same as the host used
+by the client for the request, or at least within the same
+domain if using the leading-dot notation, otherwise the cookie
+will not be set. The domain must also include at least two
+periods, so you can't set a cookie for top-level domains. See http://www.netscape.com/newsref/std/cookie_spec.html">Netscape's
+cookie specification for more details.
+
+
+CookieDomainEnv
+Syntax: CookieDomainEnv token
+
+Default: None
+
+Context: server config, virtual host, directory, .htaccess
+Status: optional
+Module: mod_usertrack
+
+
+This directive allows you to set the domain of the cookie this module uses
+for its tracking purposes based on an environment variable.
+
CookieExpires
connection, r->per_dir_config,
Re: maintaing global variable in PerlLogHandler
On Jun 23, Jim Sproull wrote: > This all works fine. However, the get_sessionid and set_sessionid are > using a dbm file, which is locked and unlocked during each request. (I > know, I know). Obviously, this is a lot more load that is necessary. I > tried using a simple global variable (defined before the handler), but this > was unreliable as it was set differently for each request. No doubt due to > different processes handling each request. Can anyone suggest a better way > of handling this globablly accessed data? Thanks. If you search the new-httpd list, you should be able to find a patch I posted to mod_usertrack (quite some time ago) that in addition to adding a configuration option (to set the cookie's domain or something like that), makes mod_usertrack create two additional notes -- "out-cookie" and "in-cookie" which are set to the value of its session cookie depending on whether it is outgoing (being set) or incoming (subsequent requests). With that, it is very easy to know when the cookie is new, and if you log the two fields seperately, you can easily calculate the number of your visitors who have cookies disabled (or only make a single request to the webserver). Jim
Re: [OT] Re: ***JOB at idealab!***
On Jun 23, Balazs Rauznitz wrote: > On Thu, 22 Jun 2000, josh schwartz wrote: > > [snip] > > > In addition, idealab! provides advice on strategy, branding and > > corporate structure. idealab! public companies include GoTo.com, eToys, >^^ > Here we go again ;)) Actually, many people attribute part of eToys recent stock dip to idealab! (or was it just Bill Gross?) divesting themselves of much of their eToys holdings. In any case, the eToys folk were quite proud of their independence from idealab! back when I interviewed with them. :) If you're looking to work in a crazy, fast-pace environment, idealab! is really a great place, speaking as someone working at an idealab!-incubated company. (And the chip they install that forces you to spell it as "idealab!" all the time doesn't hurt at all.) Their engineering group in Pasadena is an amazing group of talent, and I'm sure they're stocking the New York office with the same quality of people. Speaking of that, we're hiring too. Check out the job listings at http://www.homepage.com/jobs/programming.html and pretend you see mod_perl mentioned more than CGI. Pre-IPO, well-funded, great people (some ex-eToys employees :), cool new offices, interesting challenges, etc. Jim
Re: Apache::Request and memory
Attached is a patch to libapreq that addresses this problem.
(Doug, this may be updated since we last sent you this patch to
resolve issues with IE 4.5 on the Mac, which doesn't terminate the
MIME boundary correctly when there are fields
in a multipart/form-data form.)
Jim
On Jun 21, dorian wrote:
> Reply-To:
> hm, i guess my post didn't seem to go through.
> in regards to the handling of file uploads with Apache::Request -
> i noticed that per file uploaded, the apache process grew approximately by the size
>of the file uploaded and stayed that way. could someone possibly point me into the
>direction that would help me deallocate this memory?
>
> thanks
> .djt
diff -ruN libapreq-0.31/c/apache_request.c libapreq-0.31-new/c/apache_request.c
--- libapreq-0.31/c/apache_request.cFri Jul 2 18:00:17 1999
+++ libapreq-0.31-new/c/apache_request.cTue May 30 12:06:42 2000
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req->parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req->parms, param, value);
continue;
}
ap_table_add(req->parms, param, filename);
@@ -424,7 +425,7 @@
upload->filename = ap_pstrdup(req->r->pool, filename);
upload->name = ap_pstrdup(req->r->pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, &blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload->size += fwrite(buff, 1, blen, upload->fp);
}
diff -ruN libapreq-0.31/c/multipart_buffer.c libapreq-0.31-new/c/multipart_buffer.c
--- libapreq-0.31/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31-new/c/multipart_buffer.c Tue May 30 12:35:58 2000
@@ -57,271 +57,283 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first && little >= littleend) {
-return big;
-}
-if (bigend - big < littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen < len ? needlen : len) == 0 &&
+(partial || len >= needlen))
+ break;
+
+ /* next character */
+ ptr++; len--;
}
-bigend -= littleend - little++;
-while (big <= bigend) {
- if (*big++ != first) {
- continue;
- }
- for (x=big,s=little; s < littleend; /**/ ) {
- if (*s++ != *x++) {
- s--;
- break;
- }
- }
- if (s >= littleend) {
- return big-1;
- }
+
+ return ptr;
+}
+
+/*
+ fill up the buffer with client data.
+ returns number of bytes added to buffer.
+*/
+int fill_buffer(multipart_buffer *self)
+{
+ int bytes_to_read, actual_read = 0;
+
+ /* shift the existing data if necessary */
+ if(self->bytes_in_buffer > 0 && self->buf_begin != self->buffer)
+memmove(self->buffer, self->buf_begin, self->bytes_in_buffer);
+ self->buf_begin = self->buffer;
+
+ /* calculate the free space in the buffer */
+ bytes_to_read = FILLUNIT - self->bytes_in_buffer;
+
+ /* read the required number of bytes */
+ if(bytes_to_read > 0)
+{
+ char *buf = self->buffer + self->bytes_in_buffer;
+ ap_hard_timeout("[liba
Re: Two Apache::Request issues
On Jun 16, Tom Mornini wrote:
> On Fri, 16 Jun 2000, Jim Winstead wrote:
>
> > On Jun 15, Tom Mornini wrote:
> > > I have recently noticed two issues with Apache::Request and thought I'd
> > > run them by the list before I began hacking and diffing for Doug.
> > >
> > > 1) $ar->param without parameters has different behaviour than CGI.pm
> > >
> > > Apache::Request returns a reference, CGI.pm returns a list of
> > > parameters.
> >
> > Are you sure about this? I do this all over the place and it
> > works as documented for me.
>
> As documented? As I pointed out before, the documentation is not clear. It
> never shows $ar->param being called with no arguments in scalar context...
Ah. You didn't mention the "in a scalar context" bit or I read past
it. It's returning an Apache::Table object. The documentation should
probably get fixed to clarify that, or maybe that feature should
be removed. (Since you can get the Apache::Table using the undocumented
parms() method.)
You could force the test if the if statement to a list context by
doing something like "if (my (@args) = $ar->param))". You could also
make the test check "keys %{$ar->param}", but that won't work with
CGI.pm, obviously.
> > > 2) [Thu Jun 15 21:09:49 2000] [error] [client 10.50.2.57] [libapreq]
> > >unknown content-type: `application/x-www-form-urlencoded;
> > >charset=utf-8'
> >
> > This could probably be fixed by changing the strEQ(ct, DEFAULT_ENCTYPE)
> > to ststr(ct, DEFAULT_ENCTYPE) in c/apache_request.c on line 204. (The
> > test for multipart/form-data does this. Don't know why this one is more
> > strict.)
>
> This is great! I'll give it a try.
Saw that didn't work. There's another test at line 300 that you
need to fix in the same way.
Jim
Re: Two Apache::Request issues
On Jun 15, Tom Mornini wrote: > I have recently noticed two issues with Apache::Request and thought I'd > run them by the list before I began hacking and diffing for Doug. > > 1) $ar->param without parameters has different behaviour than CGI.pm > > Apache::Request returns a reference, CGI.pm returns a list of > parameters. Are you sure about this? I do this all over the place and it works as documented for me. > 2) [Thu Jun 15 21:09:49 2000] [error] [client 10.50.2.57] [libapreq] >unknown content-type: `application/x-www-form-urlencoded; >charset=utf-8' This could probably be fixed by changing the strEQ(ct, DEFAULT_ENCTYPE) to ststr(ct, DEFAULT_ENCTYPE) in c/apache_request.c on line 204. (The test for multipart/form-data does this. Don't know why this one is more strict.) Jim
Re: Bugs 5.6.0 modperl use?
On May 25, Jeff Stuart wrote: > That's a GOOD question. Is there anyone at the moment using perl 5.6.0 in > production? Is it ready for production yet? We have one site in production with it, and a number of others going into production soon. We've been using is exclusively in our development environment for all new development since shortly after 5.6.0 came out. It has been rock-solid for us. (The basic setup is Apache 1.3.12, mod_perl 1.24, perl 5.6.0, and FreeBSD 3.4.) Jim
Re: High-volume mod_perl based ecommerce sites?
On May 25, Barry Robison wrote:
> You may want to check out http://www.opensales.org/html/source.shtml,
> rather than starting from scratch .. I haven't used it, but it's
> a Perl based GPL commerce solution.
Every time I look at this code, my brain hurts.
Especially crap like this:
## nicedecimals( $s ) : $s;
#
sub nicedecimals {
my( $x,$y,$a,$b,$r,$i );
$i=$_[0];
( $left,$right ) = split /\./, $i;
$left="0" if (!$left);
$right="00" if (!$right);
$right.="0" if (length($right)==1);
$right = substr $right, 0, 2;
return "$left.$right";
} #/nicedecimals
Is there something this does that 'sprintf "%01.2f", $var' doesn't?
I guess it truncates rather than rounding the last digit, but I
have serious doubts that is intentional.
Jim
Re: passing Apache::File to XS code that expects FILE *?
On May 17, Matt Sergeant wrote: > Or IO::File->new_tmpfile(); I'd rather not go there. http://marc.theaimsgroup.com/?l=apache-modperl&m=95454378223412&w=2 Jim
passing Apache::File to XS code that expects FILE *?
Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? There's too much perl magic going on in the Apache::File implementation for me to see where I can just pull the FILE * out. (Its not strictly necessary that I do this, of course, it would just be nice so I can use Apache::File->tmpfile(). Of course I can do the same basic thing with POSIX::tmpnam().) Jim
Re: Newbie Question -
On May 05, Adi wrote: > You can still use CGI.pm from within mod_perl (and you should). There is > nothing better at handling data passed from a browser via HTTP POST and/or > GET. If you currently use CGI.pm, I think you'll find that a lot of your > current code can simply be cut-and-pasted into a mod_perl setup. Well, arguably Apache::Request is better at handling data passed from a browser via HTTP POST and/or GET in a mod_perl environment. And it has the advantage that is entirely focused on request handling, and doesn't have any of the HTML generation cruft like CGI.pm. (But you are certainly correct in saying that you can continue to use CGI.pm with mod_perl.) Jim
Re: libapreq and select multiple?
On Apr 27, Jim Winstead wrote:
> Is it just me, or does libapreq not handle the response from multiple> correctly? It appears to only make one of the values
> accessible.
>
> From what I can tell, this appears to go all the way down to the
> Apache::Table implementation, where the underlying Apache data
> structure does not quite have the perl semantics of no duplicate
> keys.
>
> My ideal would be for $apr->param("selectmultiplename") to return
> an array ref of the values. But I don't really have much of a clue
> of where to start to implement this.
>
> Thoughts?
Of course, $apr->param("selectmultiplename") returns an array of
the values in an array context.
Subtle. :)
Jim
libapreq and select multiple?
Is it just me, or does libapreq not handle the response from correctly? It appears to only make one of the values
accessible.
>From what I can tell, this appears to go all the way down to the
Apache::Table implementation, where the underlying Apache data
structure does not quite have the perl semantics of no duplicate
keys.
My ideal would be for $apr->param("selectmultiplename") to return
an array ref of the values. But I don't really have much of a clue
of where to start to implement this.
Thoughts?
Jim
Re: how to rewrite to a POST
On Apr 27, David Hajoglou wrote: > I need to use the post, because that is what php3 is expecting. If > anybody can think of any better way I would like to hear it. If not, then > is it possible to translate a GET uri into a POST uri with a > PerlTransHandler (or any other handler for that matter)?? Does TWIG really care whether the request comes in via GET or POST? PHP generally does not make a distinction between the two. They would have had to have gone out of their way to make this a requirement. (And one that is probably easily fixed by a search&replace of HTTP_POST_VARS with HTTP_GET_VARS.) But I've never used TWIG, so I may be missing the problem. You could write your own (very limited) "proxy" on the mod_perl side that used LWP::UserAgent to actually make the request to the backend. Not quite as easy as just leveraging mod_proxy, but I don't think it would be terribly difficult, either. Jim
Re: [OT] Proxy Nice Failure
On Apr 21, Michael hall wrote: > I'm on the new-httpd list (as a lurker, not a developer :-). Any ideas, > patches, help porting, etc. would be more than welcome on the list. > Mod-Proxy is actually kind of in limbo, there are some in favor of > dropping it and others who want it. I guess the code is difficult and > not easy to maintain and thats why some would just as soon see it go > unless someone steps up to maintain (redesign) it. There are some > working on it and apparently it will survive in some form or another. > Now would be a perfect time for anybody to get involved in it. mod_backhand may also be the solution people are after. http://www.backhand.org/ (Sorry for the off-topic-ness.) I'm also coming around to the idea that caching proxies have some very interesting applications in a web-publishing framework outside of caching whole pages. All sorts of areas to exploit mod_perl in that sort of framework. Jim
Re: Modperl/Apache deficiencies... Memory usage.
I get it. You're talking about Apache::Registry scripts. http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S Jim
Re: Modperl/Apache deficiencies... Memory usage.
On Apr 18, [EMAIL PROTECTED] wrote:
> On Mon, Apr 17, 2000 at 11:12:24AM -0700, Perrin Harkins wrote:
> > [EMAIL PROTECTED] wrote:
> > > Now with modperl the Perl garbage collector is
> > > NEVER used. Because the reference count of those variables is never
> > > decremented... it's because it's all in the registry, and it's hard to
> > > tell... hmm... what should I throw away, and what should I keep? ;-).
> >
> > What I know about Perl internals could fit on the head of a pin, but
> > this strikes me as a very odd statement. If the garbage collector is
> > never used, why do my lexical variables go out of scope and get
> > destroyed? There are mod_perl packages like Apache::Session that
> > absolutely depend on garbage collection of lexical variables to work.
> > Are you saying that destroying the variables and actually reclaiming the
> > memory are separate, and only the first is happening?
>
> Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
> the following in a perl script.
I think you're mistaken. Try the following:
package My::Test;
sub new {
return bless {}, shift;
}
sub DESTROY {
warn "destroyed";
}
sub test {
my $object = new My::Test;
print ref $object, "\n";
# object will get destroyed when it goes out of scope (now)
}
for (1..10) {
warn "t $_\n";
test();
}
__END__
Your second example doesn't do what I think you were expecting.
Jim
Re: REDIRECT missing Cookie
On Apr 08, Zeqing Xia wrote:
> Hi,
>
> I'm having a problem with setting the cookie in a REDIRECT. Basically,
> I'm doing this in a handler:
>
> $r->headers_out->add('Set-Cookie' => $cookie);
> $r->headers_out->add('Location' => $location);
> return REDIRECT;
>
> The $location is hit but the cookie is missing when I debug the handler
> for $location.
>
> I have tried various remedies, such as no_cache(),
> unset('Content-length'), etc. But nothing seems have effect.
>
> Can anyone point out what is the problem? Thanks so much.
This is a misfeature of some browsers. (Particular versions of
Internet Explorer, if I remember correctly.)
Some people have reported success with some browsers depending on
the order the headers appear, but the most bullet-proof solution
is to do a redirect with a header or meta-tag refresh instead of
an redirect. (Which is definitely not as user-friendly, but works
for all cookie-enabled browsers that I've come across.)
So you'd want to do something like:
$r->headers_out->add('Set-Cookie' => $cookie);
$r->headers_out->add('Refresh' => "0; url=$location");
$r->print("Sending you here.");
return OK;
Jim
Re: [slightly OT] Problem with cookies
On Apr 07, Randal L. Schwartz wrote: > I think this also suffers from placing the burden on the client. The > [R] there with an external rewrite means that the client will get > redirected if it doesn't tell you the right "Host:" header. But > HTTP/1.0 and older browsers (and some spiders) will NOT tell you that > header, so you get in an infinite loop. > > The solution is that you must allow for an unspoken "Host:" header to > fall through to a generic v-host. An important point is that although "Host:" wasn't required until HTTP/1.1, all of the common browsers have sent it with 1.0 requests for some time. This includes Netscape since version 2.0 and Internet Explorer since 3.0. Most browsers released since 1996 have sent it. I strongly suspect that all of the reputable search engine spiders send it as well. (That doesn't mean you shouldn't be careful and structure it so that you don't send Host-less requests into a redirect loop, I just want to make sure people know the situation isn't quite as dire as Randal may have made it sound. There are a large number of people relying on browsers sending the Host header to great effect.) Jim
Re: File upload bug in libapreq
On Jan 18, Doug MacEachern wrote: > On Tue, 11 Jan 2000, Jim Winstead wrote: > > There appears to be a file upload bug in libapreq that causes httpd > > processes to spin out of control. There's a mention of this in the > > mailing list archives with a patch that seems to be a partial > > solution, but we're still seeing problems even with the patch I've > > attached. They appear to get stuck in the strstr() call. > > > > Anyone tracked this one down before? We haven't had any real luck > > figuring out what triggers the condition that sends things into a > > tail-spin, and I admittedly haven't crawled through the code too > > carefully to see what could be going wrong. > > do you have a test case I can use to reproduce the strstr() hang bug? Not yet. We've seen it on production servers sporadically, but have not had the time to be able to take the time to properly debug it at all. (Since the simple tests I've tried have failed, I suspect it may be do to slow clients timing out their requests or some interaction with the front-end server when that happens.) I also saw the huge-memory-bloat issue that someone else reported recently with uploading a large file in a test environment (actually, uploading three files that were each around 10 megs). I'll be looking into that to see if I can't see where all that memory is being allocated, since I can actually reproduce that easily. It wouldn't surprise me if I'm just being dumb in how the file is getting copied to its final location. Jim
Re: Results of calling perl_shutdown in mp_dso_unload
On Jan 26, Doug MacEachern wrote: > =item anoncvs > > To checkout a fresh copy from anoncvs use > > cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login > > with the password "anoncvs". > > cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl Both of those should have another colon before the pserver. Like: cvs -d ":pserver:[EMAIL PROTECTED]:/home/cvspublic" login Jim
setting perl handler based on MIME type?
Is there a way to set a PerlHandler for a specific MIME type? Something like "PerlTypeHandler text/html HTML::Template"? (Yes, I know I can use a section. Not quite as slick, and that mucks up $r->location.) Jim
File upload bug in libapreq
There appears to be a file upload bug in libapreq that causes httpd
processes to spin out of control. There's a mention of this in the
mailing list archives with a patch that seems to be a partial
solution, but we're still seeing problems even with the patch I've
attached. They appear to get stuck in the strstr() call.
Anyone tracked this one down before? We haven't had any real luck
figuring out what triggers the condition that sends things into a
tail-spin, and I admittedly haven't crawled through the code too
carefully to see what could be going wrong.
Jim
--- libapreq-0.31/c/multipart_buffer.c~ Thu Dec 9 12:12:28 1999
+++ libapreq-0.31/c/multipart_buffer.c Thu Dec 9 12:18:21 1999
@@ -129,13 +129,13 @@
sizeof(char) * bytes_to_read + 1);
len_read = ap_get_client_block(self->r, buff, bytes_to_read);
- if (len_read < 0) {
+ if (len_read <= 0) {
ap_log_rerror(MPB_ERROR,
"[libapreq] client dropped connection during read");
self->length = 0;
self->buffer = NULL;
self->buffer_len = 0;
- return;
+ break;
}
self->buffer = self->buffer ?
@@ -245,12 +245,12 @@
do {
char *str;
multipart_buffer_fill(self, FILLUNIT);
- if ((str = strstr(self->buffer, CRLF_CRLF))) {
+ if (self->buffer == NULL || *self->buffer == '\0') {
++ok;
- end = str - self->buffer;
}
- if (self->buffer == NULL || *self->buffer == '\0') {
+ else if ((str = strstr(self->buffer, CRLF_CRLF))) {
++ok;
+ end = str - self->buffer;
}
if (!ok && self->length <= 0) {
++bad;
Re: Logo / brand
On Dec 04, Victor Zamouline wrote: > >"The association between the image of a white-tailed eagle and the > >topic of Apache modules is a trademark of O'Reilly & Associates." > > The association between Camel and Perl is also O'Reilly's trademark, yet we > see a camel on www.perl.com, right? This has been discussed on this list before. Check the mail archives. The bottom line is that you have to keep going to O'Reilly for permission. You're certainly never going to see another Perl book from another publisher with a camel on the cover. (And O'Reilly owns and operates perl.com, so that's not a particularly good example.) Jim
Re: Logo / brand
"The association between the image of a white-tailed eagle and the topic of Apache modules is a trademark of O'Reilly & Associates." Jim On Dec 04, Victor Zamouline wrote: > >Talking about "let's do something" topics on the mod_perl list is a waste > >of time, unfortunately... The motto of this list regarding new things is > >"think it, implement it and give it"... > > > This is somewhat too straightforward, Stas. Look - I only suggested there > should be another name and another logo, and we have already had the "Eagle" > proposition from Ged, and the watermarks samples at > http://b179a.studby.ntnu.no/mod_perl/watermark/ from Salve. > > The Eagle idea sounds really strong and symbolic behind ModPerl, and the > graphical image of it would be highly customizable, portable, simple and > color-independent. Many sites will thus accept to host the logo on the front > page, and many books will reveal a mystery behind an appealing eagle image. > > I sat down and looked at Salve's "Powered by mod_perl" watermarks for some > time, trying to imagine "Powered by Eagle"... What about "Eagle Perl"? > "Powered by Eagle Perl"? > > Vic. >
Re: libapreq-0.31 install problems on RH6.0
On Nov 27, Remi Fasol wrote: > cc -c -I../c -I/usr/include/apache > -I./auto/Apache/include > -I./auto/Apache/include/modules/perl -I -Dbool=char > -DHAS_BOOL -O2-DVERSION=\"0.31\" > -DXS_VERSION=\"0.31\" -fpic > -I/usr/lib/perl5/5.00503/i386-linux/CORE Request.c This is your problem -- that "-I -Dbool=char" is bogus. You can get the patch for (its for mod_perl itself) at: http://www.apache.org/websrc/cvsweb.cgi/modperl/lib/Apache/src.pm.diff?r1=1.13&r2=1.14 Jim
Re: Duplicated emails from mod_perl list
Looks like '[EMAIL PROTECTED]' is recycling mails back into the list, based on the headers. Probably a busted fetchmail setup or something of the sort. Jim On Nov 22, Andrei A. Voropaev wrote: > Hi! > > Probably this is off-topic. But it's about the list itself. Why do I > get OLD emails from time to time. Today I got about 7 or 8 of > those. I'm absolutely positive that I've seen them once before. Some > of those emails are dated Nov. 16th > > This happened 2 or 3 times already so I decided to ask. Maybe there's > some problem? Does anyone else gets them? > > Andrei > > --
Re: Trying not to re-invent the wheel
On Nov 10, Mark Cogan wrote: > At 10:10 AM 11/10/99 -0800, Ian Mahuron wrote: > >I may implement IF/LOOPS/etc.. but not until I see the need. > > Those introduce more complex problems. And they are, of course, inevitable with almost any templating system. Jim
Re: New mod_perl RPM really needed? (was: sourcegarden plug)
On Oct 06, David Harris wrote: > Young, Geoffrey S wrote: > > Thus, it might be worth mentioning that RPMs are a _bad_ idea for > > those just getting into mod_perl. That is, unless others have been more > > successful that I... > > I've got mod_perl running just fine with my own Apache package and RedHat's > mod_perl RPM. I understand that this keeps me from being able to use some stuff > like request chaining, but I've not had a need for it. I've also stayed away > from any mod_perl development environments (Embperl, Mason, whatver) and just > wrote the handlers all myself. > > I'm going to package all of my work up today into RPMS and publish them out to > the production servers, so I'm wondering if I should make my own mod_perl and > Apache RPM or stick with what I have working. I keep hearing that RPM's and > mod_perl are evil, but personally everything installed and worked without a > hitch. > > Oh, I remember that I had some trouble compiling libapreq, but copying a few > mod_perl header files into the system solved that without too much pain. I'll second these experiences almost exactly (down to the problems with libapreq, which is where this thread started :). I upgraded about 40 machines from mod_perl-1.19 to mod_perl-1.21 two days ago via RPM, and it went flawlessly. (And took only a few minutes since it was just done as one batch process.) I think the bottom line is that you should know your own environment. Some people seem to think anything involving RPMs precludes that. For some people, it may, but I hate to see blanket statements like "don't use RPM". A more apropros one might be "don't do anything you don't understand". Jim
