Re: [JOB] Perl Web application development with small experiencedteam
Unfortunately I'm far too busy writing Webarchitects' web CMS which promotes accessibility, usability and W3C standards, (http://www.mkdoc.com/) to help. However we at webarchitects have been subcontracting various projects (both OSS and non-OSS) with Steve Purkis ([EMAIL PROTECTED]) through his London based company quiup. As an experienced Perl programmer, software engineer, and as a company director I can tell you he's good, very disciplined, and it's well worth sub-contracting with him. That is, if you want clean code, strong test suites, and projects on time. I've CCed him this reply since he might be interested. Cheers, Jean-Michel. On Tue, 2003-08-12 at 02:46, [EMAIL PROTECTED] wrote: FastMail.FM (http://www.fastmail.fm), one of the world's leading e-mail services, is hiring an expert Perl programmer to become a Web Application Developer. In this very attractive senior position, you can work flexible hours, telecommute, and develop your skills as part of a small but very experienced programming team. You will be primarily responsible for creating cool new stuff for the FastMail.FM web interface - no meetings with marketing to attend, no team building exercises to get dragged along to..., you'll be just *writing* *code* ! To join our team, you will need to be an expert in Perl, object-oriented programming, and Web development. Ideally, you will have substantial experience with mod_perl in a production environment. As a committed programmer, you should be able to show us an impressive portfolio of your work, such as in open source projects, contributing to the Perl community, or developing new frameworks in a commercial context. Since you will be telecommuting, geographic location is not important. However, you will need good written English skills to communicate with the team over IRC and email. You will also need to be able to demonstrate a high degree of discipline and commitment to complete projects on time. Salary is negotiable -- tell us what you think you're worth! Send your application to [EMAIL PROTECTED] Please send us your resume, examples of work that you have done, links to your involvement with programming communities, references (so that we can talk to people that you have worked with), and anything else that will make you stand out from the crowd. We will monitor the mailing list and answer any questions that come up of general interest. Looking forward to seeing your application, Jeremy and Rob
[OT] About XML and Petal (was Re: templating system opinions (axkit?))
XML syntax is crufty at best. It requires you to be strict and tediously correct with every character. So what. It's not like you can afford to forget that many curly braces or semicolons (well, except those at the end of a block) with Perl. That doesn't make it useless does it? You have to shoe-horn the semantics of your complex directives into the limited syntax of element-name-and-attributes. If you're crazy enough to use XML as a programming language, I have to agree with you. XML really sucks at that. However as a data exchange format I think it's fine. I think the same idea is behind AxKit's XPathScript. Let's use programming languages to program, and XML as a vector to structure and transport data. The language becomes contrived and clumsy as a result of trying to satisfy a purity of design and you find yourself tied down to only generating valid XML (which few real world web pages are, even if they should be). Well, I see Petal's ability to help you generating valid XML webpages as a good thing. I do not recommend Petal to people who are interested in generating HTML 3.2 pages full of tables, font face tags, fixed width fonts and other javascripteries. They would be very disapointed. The templates becomes harder to read and write because they're designed to satisfy an XML parser rather than a human. By using XML directives in XML markup, you ensure that the directives are camouflaged nicely and blend into the background. This is precisely what you (well, I) don't want to happen. These directives are supposed to be important - they are a separate concern from the purely declarative markup surrounding and deserve to stand out from the crowd. I suppose that's one way of seing it. The problem is that your template then looks like a programming language, which kind of defeats the purpose of having a template in the first place. I suppose that Petal is philosophically closer to HTML_Tree, except it has a much gentler learning curve IMHO. This is all personal opinion, of course. Same here :) I drank the XML kool aid for a long time, until I realised it was nothing but water, sugar and artifical colours. XML still serves a useful purpose for many things, but it's not the uber-solution to all our problems that vendors of commercial XML software would have us believe. Just because you can write programs, or SQL queries, or templates using XML, doesn't mean that you should. I agree on that. For the record, Petal looks like a well implemented template module, and I'm glad to see another high-calibre one joining the collective. I've looked at TAL before and while I understand the design philosophy that they're trying to promote, I still not that impressed because I can see what look like gaping holes in the reasoning behind it. Maybe... It's a little bit strange when you get started with it, but it becomes clear and very elegant quite quickly. For example with a traditional mini-language kind of templating system, you might have something like: div dir=!--VAR language_dir -- !--VAR some_content-- /div Which is completely impossible to validate and IMHO very hard to read. With Petal you just start with a mockup: div dir=ltr Hello, World /div And then you add TAL instructions: div dir=ltr petal:attributes=ltr language_dir petal:content=some_content Hello, World /div If you like a more straightforward approach, Petal also lets you write: div dir=$language_dir $some_content /div But at the risk of breaking compatibility with some validators / XML tools / etc. Vive la difference! Entierement d'accord :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
If you like a more straightforward approach, TT also lets you write: div dir=$language_dir $some_content /div See, I knew there would be something that we would agree on! :-) :) But at the risk of breaking compatibility with some validators / XML tools / etc. It still looks like valid XML to me. Where is the incompatability? Am I missing something obvious? And it is. However if you have, say, div id=[% VAR object.id %] then it's not XHTML anymore (spaces / weird chars not allowed as identifier...). I'm sure there's many more cases of nasty surprises. There's also cases in which with TT or H::T you have: [% IF expression %] foo [% FOR other_expression AS stuff %] ... some stuff /foo [% END %] [% END %] Here the problem is obvious because the code is well indented. However with TAL syntax this simply cannot happen. Also, with TT you have to use the filter 'html' to XML encode your variables. Petal does it by default, and you need to use the TALES 'structure' keyword to NOT encode. This is because double encoded values are much easier to spot and debug than badly encoded ones. To summarize, I think Petal is more specialized in XML templating and has the strength of a very smart, open specification written by the Zope people. Petal fills a niche across the XML and the templating world and is certainly not a replacement for TT. Actually, as Steve Purkis suggested on the Petal mailing list it would be possible to implement Petal on top of TT. Maybe for Petal 2.00! To conclude, and in order to satisfy my little ego I think both libraries are deadly cool. Plus I would never have dreamed of the author of TT arguing about the pros and cons of TT vs Petal with me when I started writing the library a little more than a year ago. That in itself is a great reward :-) Cheers, Jean-Michel.
Re: templating system opinions (axkit?)
I've been considering using a template system for an app that I'm working, but decided against it as the designers who would be putting the actual pages together (look n feel) use Adobe GoLive which does 'bad things' to non-html stuff (at least in my experience). I know everybody's defending their fave templating system... I guess I can't resist: I have to jump in and defend my baby :) So why is Petal better than anything else? First of all, it is an implementation of TAL. TAL is a very clever open specification for WYSIWYG-friendly templates written by the Zope people. TAL has three python implementations, one PHP implementation and two Perl implementations (see Petal::CodePerl). I believe it will become the standard with which template designers will want to work with. You can open Petal XHTML templates into GoLive, Dreamweaver, Mozilla, and they will look fine. Petal is basically an implementation of TAL, an open specification designed by the ZOPE people to be WYSIWYG-compatible and which has been extensively tested with all kinds of WYSIWYG-ish software. Because Petal templates have to be well-formed XML, it is safe (and in fact recommended!) to send them through HTML tidy and check for well-formness with xmllint. Petal is not limited to XHTML. You can template any kind of XML. RSS, RDF, SVG, WML... you name it! It has good support for Unicode / multi-lingual applications and character set encoding (well, provided you use Perl 5.8). It is quite fast (templates are turned into subroutines which are cached on disk and in memory). It has been designed to be very mod_perl friendly. Petal has an active community and a mailing list, it is stable and has already been successfully used in different projects by different people. This TAL spec that I've shamelessly stolen / implemented is a really cool idea. You should really give it a try in between two Template Toolkit driven projects :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: templating system opinions (axkit?)
I know everybody's defending their fave templating system... I guess I can't resist: I have to jump in and defend my baby :) So why is Petal better than anything else? Oops, I got a bit carried away... As a side note, Petal is probably not better than anything else, but different. If you're templating XML / XHTML, it'll do a really good job. If you're templating text, use something else :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: templating system opinions (axkit?)
First of all, it is an implementation of TAL. TAL is a very clever open specification for WYSIWYG-friendly templates written by the Zope people. Do you have a URL for further reading on TAL? Yep. http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL Petal has an active community and a mailing list, Ditto - a URL would be interesting! Sure :) http://lists.webarch.co.uk/mailman/listinfo/petal Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: [mp2.0] W2000, Apache 2.0.43 + mod_perl 1.99_09 does not start
Hello, We have a problem getting mod_perl to run on a W2000 server. It does work on another machine running WinNT4, so I think there are no errors in my configuration files. Actually I'm having a windows machine at home and I got mod_perl working with ActiveState perl. I've written a howto on my personal website. You might want to try check it out, hopefully it will prove useful :) http://www.webmatrix.net/log/modperl-win32/ Hope that helps, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Another wicked mod_perl question :)
Hi List, I know that it's possible to chain Apache handlers in a way that the next handler is executed if the previous handler returned DECLINED. I would like to have the following execution chain: Handler1 Handler2 ... HandlerN CGI script (running either as pure CGI or under Apache::Registry). Any ideas on how to do that? Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
SetEnv / PerlSetEnv issue
Hi List,
I am running Apache with some perl scripts and currently I am passing
configuration variables using SetEnv, for example:
SetEnv FOO BAR
In the code:
my $foo_config = $ENV{FOO};
The problem is that I need to share these configuration variables with
mod_perl handlers. However in mod_perl handlers $ENV{FOO} is undef
despite the SetEnv directive.
So of course I tried PerlSetEnv so that I can use the dir_config()
method of the Apache object. But then $ENV{FOO} doesn't work in the CGI
script.
Everything works ok if I do:
SetEnv FOO BAR
PerlSetEnv FOO BAR
But I would like to avoid duplicating config values for obvious
maintenability issues...
Can anyone think of a way to doing a super SetEnv directive that would
set FOO in both %ENV (for CGI scripts) and in $r-dir_config() ?
Thanks for your help,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
Re: SetEnv / PerlSetEnv issue
In which request phase you try to access envar ? If you using MP1 it doesn't happen until the fixup phase (from the guide). Ok, this clears things up... I needed two config variables for my PerlInitHandler. Well, it's only a couple of variables that aren't likely to change once set, so I guess it's bareable to have them duplicated :-/. Thanks very much, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Override Authentication for one sub directory
This might be a bit OT, but since I've read somewhere on apache.org that Apache2 was using the same regex engine as Perl 5's... So I'm under the impression that with Apache2 you could do something like: DirectoryMatch ^/usr/local/systems/works/(?!open/) # your auth handler goes here /DirectoryMatch Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Authorization question
Hi List, In theory Authentication / Authorization handlers are very cool, because the application underneath it doesn't need to know the logic of it, and as long as you design web applications with nice, RESTful, sensible URIs it would all work beautifully. BUT, I cannot figure out how to 'ask' apache wether a request would succeed or not. I'm wondering wether there would be a way to do: my $ok = $r-would_be_authorized ($uri); # or my $ok = $r-would_be_authorized ($uri, 'GET'); # or my $ok = $r-would_be_authorized ($uri, 'POST', $fh); This would be handy because for example in your web application you might want certain controls or links to be replaced by proper messages rather than directing the user to a location that he/she doesn't have access to. If I missed something obvious please point out a URI so that I can RTFM! All ideas appreciated! Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Authorization question
On Thu 27-Feb-2003 at 11:39:32AM -, Richard Clarke wrote:
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r-is_intial_req())
use Apache::Constants (:common);
my $subr = $r-lookup_uri('/new/request/?foo=bar');
my $status = $subr-status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
Wow! Thanks for the tip :)
Is there a way to tell Apache::SubRequest that you're doing a HEAD / GET
/ POST / PUT / etc? Authorization handlers might behave differently
depending on the HTTP method being used.
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
Re: Authorization question
I think this may be solved by architecture. If you have an Authz layer maybe it needs to be called sooner than right when you need it. I have a Session-based auth system. When the user successfully authenticates the Auth handler does a lookup in a db where we store all users' authz information. The db has an access level for each user for each widget in the application. These are all loaded into a hashref and stored in the serverside session. An encrypted cookie has the key to the session. Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. I think it would be much nicer to write webapps on which you can plug any authorization / authentication handler chain and maintain those things as separate as possible. Then if your application uses the REST paradigm, all access control can be done using URIs, which is very neat. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Authorization question
It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. How do you mean, 'nobody'? Users certainly don't mind! Then you have to keep that information in either cookies or URLs, and there is usually a need to talk to an external data database with a site-specific schema. I admit that it's hard to get away without cookies and URI encoding schemes, but not impossible. There's a lot of tricks that you can do with path_info... For example, http://www.example.com/some/address/hello.txt,do_something This URL is easy to protect / authorize using LocationMatch directives. Basically I think you can use these simple schemes in complex applications if you're careful about your URIs. But it's true that it can be a real mindf*ck :) Basically each state of your application needs a different URI... However I find it well worth it, the promess of a truly modular, standard, pluggable authorization system is seducing, and also very 'marketable' I think. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Query
I definitely would like to get fancier as my requirement is immediate. Upon finding a server that could process the requests away from mod_perl, I most probably would modify mod_perl to communicate with the standalone servers via sockets (and maybe maintain persistence). Don't. You might want to use SOAP::Lite instead and save some hassle. But then again as said on the list, if you don't tell us what your problem is you probably won't have much helpful information. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Shroud+ Perl obfuscator....
I just want to go on the record to say that I consider your action personally offensive and ethically questionable. I agree with the 'ethically questionable' part. Copyright laws should be enough to protect your source. As far as I'm concerned if you encrypt your source it's because you want to hide the fact that you've stolen some code from somewhere else - but that's a personal point of view. However I don't find his action very offensive. This guy is just making a tool and sharing the source with us. You can't blame him for that. A lot of people have worked very hard to bring you an open source platform to stand on. And now you spit in their face, by trying to pretend YOUR work is worthy of more locking up than the source code you are using to create your work. Those people chose to work under a license which allows this kind of stuff to be done. To me it means that they have explicitly given their permission to do so. If you are - quite understandably - unhappy with this matter, make your own license for the software you write. Best Regards, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Database Pooling
My understanding is that database access via mod_perl is pooled, but only per-httpd. So if I had 10 active httpds running, I would have 10x(number of connections per pool). Not necessarily, that would be your MAXIMUM number of simultaneous connections, unless you connect to all the datababases when a children is spawn (which would be pretty dull methinks, I prefer lazy algorithms). In contrast, my Java/JSP/Servlet solution has a single pool. I'm trying to evaluate mod_perl to use instead of my current Java-based solution, but the potentially high number of database connections scares me. True, however there are many things you can do: * The easy solution: increment your database maximum simultaneous connections * I _think_ that mod_perl 2 on Apache 2 might solve your problem since it's threaded (list, am I right here? I'm still working on mp1 for the most part) * As a last resort, you can use SQL Relay [1] which looks like an ok workaround * Finally, your problem is only a problem if you're running lots of different applications accessing lots of different databases with lots of mod_perl processes :) [1] http://sourceforge.net/projects/sqlrelay/ Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: cookies and IE
Wouldn't be the first time I've been wrong. I do know that I was seeing inconsistent behavior with cookies not being saved in a redirect page (mostly IE PC, but not 100% of the time), but I didn't spend any time worrying about it because of the previous messages I remembered. A quick check of my mailbox shows a discussion back in March where someone suggested using Refresh instead of Redirect to get around the problem. I recall previous discussions, but I don't have any on file. Actually, I had the same problem with certain versions of IE not setting cookies when they are used with redirects... I ended up making it so that the redirect was unnecessary. After a while I switched to HTTP authentication - In many ways it's even simpler :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [OT] HTML to XHTML conversion
On Fri 23-Aug-2002 at 11:07:35AM -0500, D. Hageman wrote: My suggestion would to just use a XML parser module like XML::LibXML. Load the file up using the HTML loading functions and print it using the XML printing functions ... since the only difference I can see between HTML and XHMTL is that optional ending tags are no longer optional (per XML spec) and single tags must be ended properly (per XML spec). There's a lot more than that. bodybody/body/body is not valid XHTML for example. input type=text name=foo/input is not valid XHTML either. You have to be careful about block-level and inline elements. etc. etc... Besides, you cannot use an XML parser to parse HTML. You have to use something like HTML::TreeBuilder instead. Part of HTML::Tree, excellent module IMHO. Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
[OT] bOP (was: Re: [ANNOUNCE] Petal 0.1)
and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. If you are an OO-advocate, you would hide the presentation format in objects, e.g. Table, String, and Link. This ensures the output is valid through the (re)use of independently tested objects. Objects also provide a mechanism for overriding behavior. Well, there is an interesting example on this page: input type=text name=username size=25 And the question which is raised is: How does the graphic designer know that the display size of a username is 25?. Here is what you'd write with Petal: input type=text name=username size=25 petal:attributes=size user.login_preferred_length; maxsize user.login_maxlength / Then no matter what, the display size of a username would be OK. And the graphic designer could still move this tag around or change the 'size' attribute. Better, you could do the following: span style=border-style:solid; border-color: blue petal:attributes=style default_style input type=text name=username size=25 petal:attributes=size user.login_preferred_length; maxsize user.login_maxlength / /span And then the dynamic component would have a blue border when it is edited (so that the graphic designers knows that this bit of the page is subject to change) but which would be set to default_style when the page is processed... I find it really really horrible to mix HTML and Perl code. So let's say that some different kind of HTML is needed, it means that I have to create a new object, subclass an existing widget, etc... With a templating system, this can all be done by someone who has knowledge of HTML. Better, with Petal, all the presentational stuff can be done with a WYSIWYG editor a la frontpage. No need to go and tweak some strange declarative language. Actually I don't think these two things are incompatible. After all you could have 'independently tested objects' which would themselves use templates... Then you could organize your templates into two kinds: 'system / admin' templates which are related to the 'web application', you the programmer, would be in charge of maintaining these templates. 'presentational' templates which would just delegate method calls to your template driven widget library. You'd give these templates for your graphic designers to play with... And here is the HTML-less source: http://petshop.bivio.biz/src?s=View.items Well, sorry, I find it really, really horrible :-) For example: image = 'add_to_cart', field = 'add_to_cart', alt = 'Add Item to Your Shopping Cart', or: cellpadding = 2, cellspacing = 2, You are definitely tying your objects with HTML. 'cellpadding' or 'alt' are _definitely_ HTML-specific, and I don't see why they should be polluting your business logic. I see that all the code which you output is html 4.0 transitional. What if you want to make everything XHTML 1.1 strict? Or if you want to get rid of all the 'font face' tags? You want to rewrite all your widget library? Wouldn't it be easier to have templates which you can send through some kind of HTML fixed / validator such as tidy? Apologies to those who are tired of the *ML vs. Perl debate. Well, as long as we don't start trolling and that we agree to disagree we'll be fine :-) Best regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
I'm curious though, why you've chosen to implement it as a handler for XML::Parser rather than as a SAX Handler (or even better, a Filter)? What SAX buys (among other things) is the ability for folks to invisibly use whatever XML parser is installed, including a pure Perl implementation. Doing Petal as a SAX Filter would mean that it would be totally easy to add it to the mix in things like AxKit and custom SAX pipeline publishing systems. So, doing complex, multi-stage transformations like My::NonXML::SAXGenerator - Petal - SomeXSLT - SomeOtherXSLT come for free. Interesting stuff... And I think it would be quite easy to implement! At the moment Petal features two XML event generators: Petal::Parser::XMLWrapper (based on XML::Parser) Petal::Parser::HTMLWrapper (based on HTML::TreeBuilder) I suppose I could write a Petal::Parser::SAXWrapper... it would be quite trivial to generate the XML::Parser events from that :-) My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory Cache is kept fresh using the template file mtime() information. If I had a SAX event parser, then maybe caching could be a bit troublesome? Maybe what I really need would be to write something a bit more generic, i.e. my $template = new Petal ( event_generator = $event_generator, cache_key = $cache_key, cache_expires = \coderef ); I do not have much experience with SAX and pipelines or things, but if you feel like looking at the code and make sensible architectural suggestions to make Petal as generic and modular as possible then I'll be quite happy to implement them :-) Anyway, just random thoughts, really. Petal seems nice and it seems a shame to lock it in the XML::Parser-based-one-off jail. Well, it's not *really*. Take a look at Petal::Parser::HTMLWrapper, you'll see it's pretty straightforward :-) Oh by the way, Petal 0.2 is out, it fixes a stupid critical bug and a couple of documentation bugs... http://search.cpan.org/doc/JHIVER/Petal.0.2/lib/Petal.pm Best regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. I recommend that you read this Page: http://www.perl.com/pub/a/2001/08/21/templating.html?page=2 I'm an OO-advocate, I believe in proper separation of logic, content and presentation and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. After all, TIMTOWDI :-) Regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: sql-relay
What problem is that? I don't think there's much you can do beyond re-connecting, which Apache::DBI does. Well, the thing about SQLRelay is that it pools database connections, which is good when you want to have plenty of persistent connections to different databases. My only problem with it is that it doesn't seem to support prepared_cached statements... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
[OT] Need help with future CPAN template module name
Hi List, Yes yes, I am building yet another CPAN templating module which should be pretty mod_perl friendly. It will be working a bit like zope's TAL templates, i.e. you'll be able to type: ul tal:condition=object.list li tal:repeat=element object.list tal:content=:encode element.nameSome Dummy Name/li /ul Making it possible to build dreamweaver / frontpage / etc. friendly templates. Now, I'm looking for a cool name... an obvious one would be XML::Template (because it's going to be based on XML::Parser and will output only well-formed XML) although I'm not sure I can decently take such a nice namespace... I was also thinking of Petale (for Perl Template Attribute Language Engine). Any suggestions? I'll release a 0.1 version (which should be pretty workable nonetheless) on CPAN as soon as I'll get my name around a name :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [JOB] Perl / mod_perl programmer in Orem, UT
Yet again I ask myself - why don't I emigrate to the US? :-( Coz they don't have a Queen? :-) -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Better Linux server platform: Redhat or SuSe?
Owen, if you could give me any location/documentation/tutorial for how to use perlXS interface efficiently to access C progs, that will be great. You might also want to take a look at SWIG (a search for 'SWIG' on google will do as ususal), which looks quite interesting... it's a shame that I have to get some sleep at night because I wish I had the chance to take a long look at this neato piece of code. Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
[JOB] Perl / mod_perl programmer in Sheffield
Hi, I'm currently looking for a Perl / mod_perl programmer to help developing our application MKDoc. The application was originally a CGI script which has been made Apache::Registry friendly later on. We are currently gradually porting the software under proper mod_perl handlers. Given the fact that the codebase is now more than 2 years old, and that the application is doing a lot more that it was ever meant to do, being able to work with existing code and write test script suites is important. Refactoring to the rescue! Our company aims at making the CMS which produces the best websites in terms of usability, accessibility and standards compliance. And lately, unicode support, including right to left languages. So if you like these words and if you love Object Oriented Perl, this job is for you! Send me resumes and code snippets! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Better Linux server platform: Redhat or SuSe?
perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. Yes, however there are quite a number of issues with bookmarks and search engines... But that's for sure another interesting and less-ugly option. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. Yep. It's a shame that cookies which were a good idea at first get such a bad name because of all these moronic marketing companies which dream of knowing you inside out to send you more shit spam abuse them. But I'm off topic here :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
The idea is that on a location which requires authentication I'll
redirect the user to a /login.html, or maybe a /?login=1 which will do
the following:
IF user is authenticated = redirect to location it came from
ELSE send 401 authorization required
This way users should get a login box strictly when necessary. Almost
all the request go thru an Apache::Registry friendly CGI script:
Alias /.static /opt/chico/static
Alias //opt/mkd/cgi/mkdoc.cgi/
Everything is treated using $ENV{PATH_INFO} in the script, and the
script knows when something needs authentication or not.
Note that you don't have to embed session info here, just add
some element to the URL that serves as the point where you
request credentials and omit it for people that don't log in. Or
redirect to a different vhost that always requires authentication but
serves the same data.
Oh but I have that already. I know that I need to password protect
/properties.html
/content.html
/move.html
/foo/properties.html
/foo/content.html
/foo/move.html
etc...
Is it possible to password-protect a class of URIs using regexes? That
would be another good option.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Thanks to the list and two days of hard work, I have my optional HTTP
authentication thingie working :-)
Basically here is how it looks in my apache config file:
# This method handler ensures that users must enter their credentials
# for any URI which looks like /foo/bar/login.html
LocationMatch .*/login.html$
AuthName MKDoc Login
AuthType Basic
PerlAuthenHandler MKDoc::Auth::SQL_HTTP-handler
require valid-user
/LocationMatch
# This method handler affects the whole site, it sets the
# $ENV{REMOTE_USER} variable if the credentials have been sent, or
# leave it undef otherwise.
Location /
PerlFixupHandler
MKDoc::Auth::SQL_HTTP-handler_opt
/Location
# if the user successfully logged in when hitting a /foo/bar/login.html
# location, then we want to redirect him where he came from
LocationMatch .*/login.html$
SetHandler perl-script
PerlHandler
MKDoc::Auth::SQL_HTTP-handler_redirect
require valid-user
/LocationMatch
more perl handlers here
* Now if you go to /properties.html BEFORE sending the credentials,
* You're redirected to /login.html?from=/properties.html where you login,
* Which redirects you to /properties.html... but this time your browser
sends the credentials!
This is interesting because it's up to the handlers to decide wether
they need authentication or not and does non depend on the location.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
a href=/adminAdmin this page/a will be possible.
This is not true, once you've entered the credentials on /login.html the
browsers send them everywhere. Tested under Opera (Linux), Mozilla
(Linux) and IE from version 3 to version 6 (Windows), IE 3 (Mac),
Netscape 4 (Mac).
One exception: links :-(. But the browser support seems to be there...
In the future I plan to have some kind of hybrid handler which would
accept either HTTP credentials OR a cookie... that would be cool :-)
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Well I seem to have done it, so it must be possible thanks to you guys
;-. I will send the code to anyone who's interested but I don't want
to post it to the list because I suspect that most people aren't.
Thank you everyone,
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Optional HTTP Authentication ?
This seems a little off topic. I think this is an architecture question, not a mod perl question. Well, a bit of both I guess. Basically, you want all you protected files to be located in /protected or some other directory... No that is not possible. I am running a web application, there are no such things as 'files' (everything is done using PATH_INFO), only locations. Users can create as many locations as they want (i.e. /foo/bar/) and administrate them using URIs such as /foo/bar/properties.html, /foo/bar/contents.html, etc. There are some locations which do not need to be protected, i.e. /foo/bar/ /foo/bar/print.html /foo/bar/dc.xml /foo/bar/rss100.rdf But some others need to, like: /foo/bar/properties.html /foo/bar/contents.html /foo/bar/move.html etc. I want to use HTTP authentication for that, but of course I cannot password protect the whole site, because public users would not be so happy! Any ideas? -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Optional HTTP Authentication ?
Oh, I don't know, I think the poster was asking about how to produce this
effect with mod_perl. He wants to know *whether* a login was provided, even
on a *non-protected* page. That would let you say (while serving any old
page):
if( $ENV{REMOTE_USER} eq 'admin' ) {
$r-print('Yo, you can do a href=/admin/extra kewl stuff/a here.');
}
Yes, that is quite the case.
In one of the earlier stages of processing - maybe a FixupHandler or ? a
AuthenHandler might be appropriate - you can do something like this:
my $a = $r-header_in('Authorization');
$a =~ s/^Basic (.*)/$1/;
my( $user, $pass ) = split(':', decode_base64( $a ) );
if( check the username/password as you wish ) {
$ENV{REMOTE_USER} = $user;
}
So, now you can tell later during the request with a username/password was
offered (and you know it was a valid login/pass combo).
That's very interesting! I don't think I can use an auth handler because
then I would have to password protect the whole site (which I don't want
to).
I want to have just ONE page which is password protected (i.e.
/login.html). The page would just be a redirect, but once the user
entered his credentials then the browser should send them on the whole
site and then I could do the following:
/foo/properties.html
IF authenticated
IF authorized = trigger /foo/properties.html
ELSE = send custom error page
ELSE
redirect to /login.html?from=uri
Anyway I'm going to try that fixup handler thingie and I'll tell you how
it goes :-)
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
It seems that Apache::AuthCookie allows a way to make areas to which one can authenticate if s/he wants. I suppose that then in those areas you can tell if the user is logged in and affect the pages if so. Indeed the best option would be to be using one of the Apache::Session module and use the provided hash to store the login information. I have read the whole portion of the eagle book dedicated to authentication / authorization before posting my crack-smoked question to the list ;-) Unfortunatly: * For political reasons and compliance with future european legislation I cannot use cookies, * For usability reasons encoding session IDs on URIs would be really bad... users needs to be able to 'hack' the URIs without f***ing their sessions! Therefore I have to use HTTP authentication... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: param trouble
basically the whole thing is starting to bite its own tail and i would be very happy if anybody could give me any pointers as to why CGI won't read my data from the PerlInitHandler or after Apache::Request read them. I seem to remember a post where someone had trouble because he was trying to access POSTed data twice... problem was that once the POSTed data was read, that was it. Maybe it's something similar? Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
What? The EU is going to make cookies *illegal*? I highly doubt this. Sorry, I am neither the lawyer nor the client, so I can't tell you... I know it's really stupid, but I am going to have to deal without cookies. Jean-Michel * For usability reasons encoding session IDs on URIs would be really Jean-Michel bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel sessions! Why is a user hacking their URLs? I can answer that. http://www.useit.com/alertbox/990321.html cite * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are hackable to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change /cite i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=56765454151 is not. Again it doesn't always make implementation easy :-/ Jean-Michel Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. I have to agree with you on that. Cookies are probably far better than HTTP authentication. But I cannot use cookies. Period. I wish I could, because this was what I did in the first place and it was working fine! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
Please check that the idea of this kind of authentication is to encrypt the
ticket, instead of a plain session ID. If cookie is not available, having
it on URI is a good idea. (Then one needs to have all links in a relative
manner; see the Cookbook). Cookie itself does not make a secure session ID
or a secure ticket. It is the encryption that does.
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going to have to stick with it no matter what... My problem is:
How do I tell apache to set the $ENV{REMOTE_USER} variable if the
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Optional HTTP Authentication ?
In one of the earlier stages of processing - maybe a FixupHandler or ? a
AuthenHandler might be appropriate - you can do something like this:
my $a = $r-header_in('Authorization');
$a =~ s/^Basic (.*)/$1/;
my( $user, $pass ) = split(':', decode_base64( $a ) );
if( check the username/password as you wish ) {
$ENV{REMOTE_USER} = $user;
}
OK, I got this working using a fixup handler BUT there is a nasty trap.
It happens that the environment variables which you set from Perl aren't
inherited from sub-processes... which means that this technique is fine
if the script that comes after authentication runs under
Apache::Registry.
Unfortunately, I might need the script to run under mod_cgi... I
couldn't find how to tell the apache server to set environmental
variables in the mod_perl pocket reference, anyone has got an idea?
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Moving WYPUG
I now need to install some Perl modules (DBD-MySql, Image-Magick, etc). Under ActivePerl on WYPUG's current Win2K box, I would simply use the Perl Package Manager (PPM) to download and install these modules. Is there an equivalent under Unix? If not, what's the best way to install modules? In short, what do I need to know? You might be willing to spend some time setting up CPAN.pm. It's a bit of a hassle to get it working right, but once you're done it feels just like PPM :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
On Tue 12-Feb-2002 at 04:02:47PM -0500, Perrin Harkins wrote: A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. This is how perl works. You are not allowed to have two different modules with the same name loaded in the same interpreter. If you can't deal with that, maybe you should consider using an environment like Mason or Embperl which allow a page-based approach closer to PHP, rather than using perl's package namespace. I know that this is how perl works... in the context of mod_perl though, in some cases it'd be less hassle to be able to have persistent perl processes isolated per script or per host... Anyway if mod_perl 2.0 allows a pool of perls on a per-host basis as you said, then it'd be a great plus! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! Global variables are variables without scope. They are not cleaned up by definition. If you want variables that go out of scope, use lexicals. If you have legacy code that depends on mod_cgi behavior to work, use Apache::PerlRun which clears globals on each request. Apache::PerlRun is far too slow (I don't wanna recompile 18.000 lines of Perl code on each request, thanks :-)). Global variables are useful to store objects that can be accessed anywhere. The only way out is to manually undef everything on each request... I suppose it's not so bad, but I'm just a lazy bastard thus I need to complain :-) * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? Doug has talked about doing something with this in mod_perl 2 to help clean up memory taken for lexicals, but it's not definite. And yes, this is really a Perl issue, not a mod_perl one. Yeah Perl not cleaning cyclic references is a pain. And WeakRef is a horrible hack :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
The thing is I am getting some weird behaviour where one application seems to be getting code from the other. In theory this isn't possible with the separated namespaces. I suspect my UNIERVSAL use is the problem. Can anyone verify this? Is it a known problem? Is there any way around it? To my knowledge, the only namespace which is separated is package main. I don't know about you guys, but I think it would be great if mod_perl could be as painless as mod_php. Don't get me wrong, I think that PHP as a language is absolutely fubar, however mod_php is fast, secure, isp friendly and does not have so many problems as mod_perl. A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) These are the - painful - issues I discovered during the last 6 month of intensive mod_perl coding. I hope they'll be fixed at some point because mod_perl could be so popular if they were! Allright I'll stop whining and go back to some coding ;-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
* If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... Consider this. I develop a piece of software in Perl which is quite big. Therefore it's split into a horde of modules. Now do these modules changes between versions? Yes (bug fixes, improvements, API changes, etc). Do the modules name change? Nope! As a result I had to amend the software so that it can run multiple websites. But then if there is a need to change the logic of just one site I can't just go and change one module because it would change it for everything else. In other words it'd be nice to be able to run different versions of the same software for different websites on the same server (via virtual hosts). And that doesn't work. Besides this: with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... is highly bullshit. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. The developer does not want to rename his module (I understand that). Even if I install / compile the module locally, mod_perl is going to screw everything up! Great! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. I think this is wrong. Variables should be reinitialized by default, or persistent if specified otherwise in some config file. * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... intentional functionality. I though that bugs were called features, but this is even better. I'll have to remember this one :- don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing True, however the real point of Apache::Registry is to run unaltered CGI scripts under mod_perl and it just doesn't work properly does it? Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Do you know where to find mod_perl 2 related info on the web? I'd be interested in knowing what's it gonna be. Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Apache::Registry HEAD fix
Hi mod_perl Geeks, A few weeks ago I raised the issue of Apache::Registry issuing incorrect headers in the case of a HEAD request, as it's also returning the headers. Geoffrey Young came up with a subclass of Apache::RegistryNG, and I forgot everything about it until yesterday, when I realized that it was working with none of my scripts :-/ Anyway as promised, (late, but...) here is something that seems to work OK and that's not _too_ hackish. Please take some time to test it, and maybe change the module name :-) Tell me what you think! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM Registry.pm Description: Perl program
Re: Apache::Registry HEAD fix
I tried it with the product I'm working on and it just kept outputting blank body data. hmph. very odd. I guess we need to trace the output to see what's going on. Yep. Lots of wierdness... The only thing I can assure is that the script works fine under mod_cgi, and is messing with Apache objects at all. I am now using a very simple script and I have realized that my solution does not work in all cases either :-) yes, that's what I pointed out before :) http://marc.theaimsgroup.com/?l=apache-modperlm=100687034903369w=2 Wow, that's different now. I'm not redirecting to /dev/null but to a temp file from which I extract the headers. ok. in true programmer fashion, of course I think my approach is better :) at least, it seems less hackish to me, and playing with STDOUT just isn't typical in mod_perl, since it's really tied behind the scenes. Well actually I tend to agree with that. I don't really like the fact that I need to create temp files, nor redirect STDOUT. But hey, I'm just trying to get this stuff working OK... and I can't find any decent online API reference for Apache::RegistryNG. Besides, the edition of Writing Apache modules with Perl and C that I'm using doesn't seem to cover all Apache::Registry API. Sigh... anyway, if you send me a sample script I can play with it some. for the most part, my stuff is code ripped right from mod_perl core, but there could be something subtle going on that is easily fixable. Okay dokay. I'll stop playing with my mailer and try to do some debugging work now :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: CGI module bug, Internet Explorer 6 problems and workaround...
Hope this helps any people who encounter the same problem. Though it of course raises the question, is the XHTML incorrect in someway to cause IE to barf, or is IE barfing incorrectly? I do work on a product (http://www.mkdoc.com) which outputs mainly valid XHTML, and it works fine with any browser basically. Have you tried to use an XHTML validator on the XHTML code that is being generated? Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: transient object data
By attribute do you mean an element of the data structure that is blessed in the object? Or do you mean some sort of new attribute you would assign a new Serializable data type (ala something to suggest for Perl 6). I think that what Brian was trying to say is that you could mark an object attribute as being transient and Data::Dumper would ignore it. Maybe the way to do it would be to have a Serializable class that could have the following methods: freeze($self) : SCALAR thaw ($class) : OBJECT clone($self) : OBJECT; _freeze($self): SCALAR _remove_transient_attributes($self); The transient attributes names could be stored in @TRANSIENT. Maybe we could also have a more generic $TRANSIENT coderef as well. Whenever you want to serialize an object calling freeze, then the object is cloned and the clone gets its transient attributes removed. That we can call _freeze on the modified copy. With this interface it would be possible to subclass Serializable with Serializable::FreezeThaw, Serializable::DataDenter or Serializable::XMLDumper for instance (just override the _freeze and thaw methods). The objects can also redefine the clone() method if they need to. Now there's only one drawback that I can see - It needs to be written :-) Cheers, -- Jean-Michel Hiver.
Re: Tips tricks needed :)
If you're developing a complex application, you'll probably want to
split it in a horde of specialized modules. Few things to remember:
==
You will probably feel the need to use static variables (i.e. variables
shared with all instances of a given class) at some point. For example
if you have a singleton object you might have something like that:
package Your::Singleton;
use strict;
use 5.6;
use our $ETERNAL = undef;
sub instance
{
my $class = shift;
return $ETERNAL if (defined $ETERNAL);
$ETERNAL = $class-new (@_);
return $ETERNAL;
}
sub new { ... blah blah code ... }
1;
ALWAYS reinitialize $Your::Singleton::ETERNAL on each query!
mod_perl will *NOT* do it for you.
You might think 'ah yeah but it would be nice if
$Your::Singleton::ETERNAL could be persistent across queries...' which
is sometimes desirable, but remember that if you have multiple instances
of your application running on the same apache,
$Your::Singleton::ETERNAL will be common to ALL of them.
==
Cyclic memory references are dangerous, try to avoid them as much as
possible! Perl garbage collector does miserably fails in the case of
cyclic refs.
If you have a cycling references that keep going out of scope, they will
never be garbage collected and your server might have some trouble :-)
==
Beware of regular expressions /o modifier! The application I'm working
on has a cool feature heavily using regular expressions: automagic
hyperlinking of text / html data when appropriate. I used to use the /o
modifier and got a few nasty surprises (until I discovered the mod_perl
guide traps page)
==
Other than that, more generally speaking:
Always hide classes implementation with method calls! Not so long ago I
did tend to write using less method calls and directly accessing
object's attributes and now this is my #1 source of maintenance problem
and headaches.
It you think it's too slow then consider it's better to buy a bigger CPU
than 3 tons of aspirin. Also avoid using packages names inside functions
as much as possible, as it tends to screw inheritance.
Finally my biggest piece of advice:
ENFORCE a coding style. ENFORCE using english for variable, function
names and comments (for example although I'm French I really can't stand
code written with french variable names and comments! The Perl language
is using English keywords after all. Be consistent FFS) . ENFORCE
commenting what every single method does.
Having said that I do naturally tend to write awful code that only I can
understand, but at least everything is properly commented :)
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 221 4968
VISIT HTTP://WWW.MKDOC.COM
Re: Tips tricks needed :)
On Wed 19-Dec-2001 at 10:43:34AM -0500, Perrin Harkins wrote: ALWAYS reinitialize $Your::Singleton::ETERNAL on each query! mod_perl will *NOT* do it for you. If you want a per-request global, use $r-pnotes() instead of a standard perl global. Then mod_perl *WILL* do it for you. True. But then you are using the Apache object and you're program doesn't work as a standard CGI anymore :( You might think 'ah yeah but it would be nice if $Your::Singleton::ETERNAL could be persistent across queries...' which is sometimes desirable, but remember that if you have multiple instances of your application running on the same apache, $Your::Singleton::ETERNAL will be common to ALL of them. It will be common to all requests in that particular process, but not shared between multiple Apache processes. If you take requests for different applications that need different singletons on the same Apache process, you should separate them by namespace so they don't collide. Yup, that's what I meant. Separating by namespace is not very convenient though. What I have been doing to get around this is that I wrote a simple module that can be used as a global scalar and that uses tie to return appropriate variable (FYI I've attached the module, if that interests anyone). Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM MPH.pm Description: Perl program
Re: Preloading Fcntl.pm
Wouldn't that affect mod_perl's advantage of sharing the modules? I mean, would everything be in it's separate namespace and loaded only once for every module as it is with use? I don't know about you guys, but I don't feel that sharing the modules is that much of an advantage. If you write large scripts that actually use modules of your own which can be different depending on the version of the script, it means that you cannot run different versions of the script on the same box, which IMHO is not very convenient... Do you know if there's a way to avoid this? Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: Apache::Registry HTTP HEAD feature fix ;-)
this should work for scripts that only use print() (without the patch I sent yesterday :) Looks neat! I'll make sure I'll take a close look at that :-) Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: [modperl-site design challenge] Thomas Klausner (domm)
On Mon, Nov 26, 2001 at 01:36:07AM +0100, Robin Berjon wrote: * The first page (Home) successfully validates at w3.org (HTML and CSS). That's very good. Do the others validate as well (or at least, do you see any reason why they wouldn't ?) ? On some of the deeper pages, Pod::POM generates HTML like this: ul text /ul This isn't valid HTML (according to W3C), so those pages won't validate successfully. e.g: http://domm.zsi.at/modperl-site-domm/download/binaries.html Maybe you should use HTML tidy to automagically fix broken HTML? Another thing is that accessibility guidelines recommend using XHTML 1.1, since your HTML looks pretty clean and simple you might want to do that instead of using old HTML 3.2. Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HTTP HEAD feature fix ;-)
well, you should be subclassing Apache::RegistryNG instead of Apache::Registry - then your method calls would work :) Sorry, Although I'm good at OO-Perl and CGI programming, I'm really quite new to mod_perl thus I really don't know what the fuck I'm doing :-) What is the difference between Apache::Registry and Apache::RegistryNG ? (a simple RTFM followed by a URI would be welcome). personally, I'm not too keen on a core patch that comes with I don't understand why... but it works and this approach seems kinda kludgy anyway... I totally agree, it's a horrible hack, and I'll be willing to provide something much better when I understand what's going on and why Apache::Registry seems to be reluctant to let its methods change ;-) Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HTTP HEAD feature fix ;-)
well, I just gave you a patch that worked :) basically, it only provides a solution for mod_cgi compatible scripts, but if you're using the mod_perl API then it is up to you to check $r-header_only and take appropriate action... True, however your patch also means that it's necessary to recompile stuff, which is not always possible. In addition (and as an exercise) I'd be happy to find a clean Perl way to do it. Best regards, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Apache::Registry HTTP HEAD feature fix ;-)
Hi guys, As promised I have been producing a fix for Apache::Registry. The module is called MKDoc::Registry because it will be integrated in the piece of software I'm working on, but feel free to do whatever you want with it. A slight litte issue is that I really don't understand why this module is working at all (read the code), but it's just working fine... could you please test it and tell me what's going on? PS: On my system the file is located here: /usr/lib/perl5/site_perl/5.6.0/i386-linux/MKDoc/Registry.pm Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / === Registry.pm Description: Perl program
Apache::Registry HEAD request also return document body
Hi all, I have a problem with HTTP head requests and mod_perl. I have been looking at the docs, searching google newsgroup archive but I couldn't find anything thus you are my very last hope ;-) In order to show what the problem is, I have set up two simple identical 'Hello World' type CGI scripts on my machine. One is running under Apache::Registry, the other is running as a plain old CGI. Here is what I get: not_mod_perl test (plain CGI, everything works fine) = [root@frogette /]# lynx --dump http://not_mod_perl Hello World! [root@frogette /]# lynx --dump -head http://not_mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:22:37 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain mod_perl_test (mod_perl, headers are fubar) = [root@frogette /]# lynx --dump http://mod_perl Hello World! [root@frogette /]# lynx --dump --head http://mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:24:50 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain Hello World! PROBLEM HERE A head request should * NOT * return the body of the document Obviously this is very wierd! You can find more details on the config in the attached file. Any ideas on what's going on? Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / === Added these two lines in /etc/hosts === 127.0.0.1 mod_perl 127.0.0.1 not_mod_perl This is the test script, test.cgi = #!/usr/bin/perl print Content-Type: text/plain\r\n\r\n; print Hello World!; This is /opt/mod_perl/httpd.conf. It is included in my apache httpd.conf (mod_perl enabled test.cgi) VirtualHost 127.0.0.1 ServerName mod_perl ServerAdmin root@mod_perl CustomLog /opt/mod_perl/www_combined_log combined ErrorLog/opt/mod_perl/www_error_log Alias / /opt/mod_perl/test.cgi Directory /opt/mod_perl SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On # directives for CGI. These should work everywhere # do not uncomment that bit of text Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none /Directory /VirtualHost This is /opt/not_mod_perl/httpd.conf. It is included in my apache httpd.conf (mod_perl disabled test.cgi) VirtualHost 127.0.0.1 ServerName not_mod_perl ServerAdmin root@not_mod_perl CustomLog /opt/not_mod_perl/www_combined_log combined ErrorLog/opt/not_mod_perl/www_error_log Alias / /opt/not_mod_perl/test.cgi Directory /opt/not_mod_perl # SetHandler perl-script # PerlHandler Apache::Registry # PerlSendHeader On # directives for CGI. These should work everywhere # do not uncomment that bit of text Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none /Directory /VirtualHost Added this in /usr/local/apache/conf/httpd.conf Include /opt/mod_perl/httpd.conf Include /opt/not_mod_perl/httpd.conf Restarted apache not_mod_perl test = [root@frogette /]# lynx --dump http://not_mod_perl Hello World! [root@frogette /]# lynx --dump -head http://not_mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:22:37 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain mod_perl_test = [root@frogette /]# lynx --dump http://mod_perl Hello World! [root@frogette /]# lynx --dump --head http://mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:24:50 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain Hello World! PROBLEM HERE A head request should * NOT * return the body of the document
Re: Apache::Registry HEAD request also return document body
Hi, Thanks for your quick answer, PROBLEM HERE A head request should * NOT * return the body of the document You should check $r-header_only in your handler. http://thingy.kcilink.com/modperlguide/correct_headers/3_1_HEAD.html My only concern is that I thought that Apache::Registry was designed to act as a CGI emulator, allowing not so badly written CGIs to have mod_perl benefits without having to change them. If I have to use the $r object (and therefore the Apache module), then it means that the scripts won't be able to run as standalone CGIs... Am I right? -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HEAD request also return document body
Try HEAD on this script.
#!/usr/local/bin/perl -w
use CGI;
my $q = CGI-new;
print $q-header, $q-start_html,
join( BR\n, map { $_ : $ENV{$_} } keys %ENV),
$q-end_html;
I'm still getting the headers. I also have this behavior on other boxes
(one on our redhat server and on one of our client's solaris server),
thus I suppose it's not a platform issue.
Here is how it looks on my box:
[root@frogette /]# cat /opt/mod_perl/test.cgi
#!/usr/bin/perl -w
use CGI;
my $q = CGI-new;
print $q-header, $q-start_html,
join( BR\n, map { $_ : $ENV{$_} } keys %ENV),
$q-end_html;
[root@frogette /]#
[root@frogette /]# /usr/local/apache/bin/apachectl restart
/usr/local/apache/bin/apachectl restart: httpd restarted
[root@frogette /]#
And here is what I get:
[root@frogette /]# lynx --head --dump http://mod_perl
HTTP/1.1 200 OK
Date: Fri, 23 Nov 2001 15:14:24 GMT
Server: Apache/1.3.19 (Unix) mod_perl/1.25
Connection: close
Content-Type: text/html
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN
HTMLHEADTITLEUntitled Document/TITLE
/HEADBODYQUERY_STRING : BR
HTTP_ACCEPT_LANGUAGE : enBR
REMOTE_PORT : 34961BR
HTTP_USER_AGENT : Lynx/2.8.4dev.16 libwww-FM/2.14 SSL-MM/1.4.1
OpenSSL/0.9.6BR
HTTP_ACCEPT : text/html, text/plain, audio/mod, image/*, video/*,
video/mpeg, a
pplication/pgp, application/pgp, application/pdf, message/partial,
message/exte
rnal-body, application/postscript, x-be2, application/andrew-inset,
text/richte
xt, text/enriched, x-sun-attachment, audio-file, postscript-file,
default, mail
-file, sun-deskset-message, application/x-metamail-patch,
application/msword, t
ext/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png,
image/x-x
bitmap, image/x-xbm, image/gif, application/postscript, */*;q=0.01BR
PERL_SEND_HEADER : OnBR
HTTP_HOST : mod_perlBR
GATEWAY_INTERFACE : CGI-Perl/1.1BR
SCRIPT_NAME : /BR
SERVER_NAME : mod_perlBR
HTTP_ACCEPT_ENCODING : gzip, compressBR
MOD_PERL : mod_perl/1.25BR
SCRIPT_FILENAME : /opt/mod_perl/test.cgiBR
PATH :
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jhiver/bin:/opt/j2sdk1
.3.1/bin:/usr/local/binBR
SERVER_ADDR : 127.0.0.1BR
SERVER_PROTOCOL : HTTP/1.0BR
SERVER_SIGNATURE : ADDRESSApache/1.3.19 Server at mod_perl Port
80/ADDRESS
BR
SERVER_SOFTWARE : Apache/1.3.19 (Unix) mod_perl/1.25BR
SERVER_ADMIN : root@mod_perlBR
REMOTE_ADDR : 127.0.0.1BR
DOCUMENT_ROOT : /usr/local/apache/htdocsBR
REQUEST_URI : /BR
REQUEST_METHOD : HEADBR
SERVER_PORT : 80/BODY/HTML
[root@frogette /]#
Duh... That's a lot of info for a head request :-)
Cheers,
--
== \__ =
/\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB
/ /\__/\ \
_/_/_/\/\_\_ Jean-Michel Hiver - Software Director
\ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968
\ \/__\/
\/\ VISIT HTTP://WWW.MKDOC.COM
== / ===
Re: Apache::Registry HEAD request also return document body
You can subclass Apache::RegistryNG to do what you want and send the patch for others to re-use. The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Thus I guess if I have to amend Apache::Registry it might be worth submitting a pach for a bugfix rather than a subclass of this module wouldn't it? The idea is interesting but while the implementation is possible it won't give any speed benefit. The positive effect that can be achieved is returning the caller exactly what it has asked for. I don't understand you here. It might not give any speed benefits in computing the headers, sure. But there are number of things that you might want to be in the headers (like date last modified, md5 checksum, content language, content length, etc) and they need the whole page to be computed anyway. You could argue that sending minimalistic headers to speed up head requests is possible, but then you're fucking proxies which are there to save you bandwidth and CPU anyway. When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. Maybe there should be an option, like ManageHeadRequests [On|Off] The option might be 'Off' by default for backwards compatibility. That would do the Right Thing whenever a HEAD request is invoked on the script. I'm quite surprised that this whole issue doesn't seem to have been raised yet - or maybe I missed something? What do you guys think? Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HEAD request also return document body
On Fri 23-Nov-2001 at 11:45:19PM +0800, Stas Bekman wrote: did you mean to reply to the list? before I reply? Sorry I screwed up because my mailer doesn't know yet that [EMAIL PROTECTED] is a mailing list. I guess it's time to go tweak my muttrc file ;-) So here is a cleaner repost: You can subclass Apache::RegistryNG to do what you want and send the patch for others to re-use. The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Thus I guess if I have to amend Apache::Registry it might be worth submitting a pach for a bugfix rather than a subclass of this module wouldn't it? The idea is interesting but while the implementation is possible it won't give any speed benefit. The positive effect that can be achieved is returning the caller exactly what it has asked for. I don't understand you here. It might not give any speed benefits in computing the headers, sure. But there are number of things that you might want to be in the headers (like date last modified, md5 checksum, content language, content length, etc) and they need the whole page to be computed anyway. You could argue that sending minimalistic headers to speed up head requests is possible, but then you're fucking proxies which are there to save you bandwidth and CPU anyway. When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. Maybe there should be an option, like ManageHeadRequests [On|Off] The option might be 'Off' by default for backwards compatibility. That would do the Right Thing whenever a HEAD request is invoked on the script. I'm quite surprised that this whole issue doesn't seem to have been raised yet - or maybe I missed something? What do you guys think? Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HEAD request also return document body
Hi All, Well, you won't save CPU if you need to compute the whole page anyway... And we're talking of dynamic generated pages, most won't be cached, and those that will might as well send an Expires: header, in which case the proxy and browser will cache the data unless the user forces the cache to be skiped. You have a point. It's not so much a big deal for me because I cache things on the server side anyway, but I can see what you mean. The option might be 'Off' by default for backwards compatibility. Backward compatibility with a bug? I don't even think there should be a Off setting. Sending the content in a HEAD request is, IMHO, a violation of the HTTP protocol. It is: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4 cite The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. /cite However some people might have been using the Apache request object to prevent this already. We don't want them to change their code do we? Some other people are unaware of the problem and perfectly happy with it. Fine. Now for all the others (and that includes me :)) it'd be nice to have an option to have the correct behavior. I might just have a look at Registry.pm this week-end and see what kind of horrible hack I can do. Also, I think the handler shoulnd't just terminate the script, but send the output until the end of the headers (the first blank line), close the connection, but wait till the scripts ends by it self. Killing it could provoke database corruption or similar problems... Agreed, in fact it should grab the whole output, or do something with STDOUT when the headers have been printed or something. And another one, Fake or Skip that would just return standard ones, without even bother to run the script... Then the admin will be able to choose the best for it's cause... That would be very bad because the script might return a content type which is something completely different from text/html... unless this is clearly documented as being very bad / dangerous indeed. Okay, so far we might want to have something like: ManageHeadRequests Off|On|Skip It might also be nice to have a 'Fat' option that would put as much info in the head as possible, like language, content-length, link rels, etc (yeah, mozilla supports link rels in the headers, believe it or not :-)) Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
