The Un-Official Proxomitron Forum

Hi all,

If I remember correctly, Scott wrote proxo with perl. A while back, I downloaded perl from activestate, but I didn't see how you could make a stand alone program with a windows gui with it.

If anybody could shed some light on this, I'd appreciate it.

Mike

Mike;

Quote:If I remember correctly, Scott wrote proxo with perl. A while back, I downloaded perl from activestate, but I didn't see how you could make a stand alone program with a windows gui with it.

If Scott had used perl to write Proxo, he would have been certifiably commitable within hours of starting the attempt! I'm a perl programmer myself, and look at me!! (On second thought, that might not be such a good idea. [angry])

What he did do was kype the general idea from a perl script written many years ago. That script, which is still around, btw, was used by SysAdmins to remove objectionable content from emails and webpages posted by university students with, shall we say, a penchant for the more shocking elements of the language. This was even before the days of the true Internet, as devised by Tim Berners-Lee.

But I doubt very much that Scott actually programmed Proxo in perl. It just doesn't lend itself to building executable apps, let alone a GUI to go with it. Kopeks to donut holes, he used a much more modern language, although I never asked him, so I'm not the final authority on this.

Mind telling us what's your reason for asking this question? BTW, if you need help with perl programming, just ask. If I can't answer it, I'll be more than happy to point you to some of my favorite resources. :P


Oddysey

p.s. Hope you all can find this message - it's my "404" th one!!

Hi Oddysey

Thanks for the reply.

Oddysey Wrote:It just doesn't lend itself to building executable apps, let alone a GUI to go with it.

Well, too bad. I was hoping that I was missing something there.

I was contemplating writing a "proxo" like program without reinventing the wheel. Perls regex capabilities looked powerful and if I remember right, I recall seeing there was a proxy module already written for it. Perl really seemed to have everything that I was looking for, plus its free & isn't Windows specific.

For me, proxomitron is the only reason I haven't switched to another OS for use at home. Also, I'm concerned that proxo will not be compatible with a future MS update or upgrade. After using proxomitron for so long, I can't imagine browsing without the web filtering power that it offers.

I think writing such a program would be worthwhile and no doubt I would learn much. On the other hand, I keep thinking that someone else will do it so why bother.

Any thoughts on this?

Mike

Mike,

Quote:Any thoughts on this?

Do I got any thoughts on this? Is a bear Catholic? Does the Pope sh1t in the woods? Sure, I've got thoughts on this, some of 'em are even printable in a family-oriented newpaper!

For one thing, I am also hanging around in the Windows world solely due to Proxo. If there were an equivalent proggie in the Linux domain, I'd be outta here so fast that it would take 5 minutes for air to finish filling the vacuum I left behind, I'd be gone so fast! That said, there's another thing to remember, and that is: compiled executable files are not always the best solution for each and every problem. Sometimes, an interpreted program (often called a script) can be just as effective, and occasionally, even more so.


On using perl to make the Web a safer surfing experience......

I don't doubt that there are perl modules out there that can do filtering on the level that Proxo can accomplish, but they will be running in an interpreted environment, and that requires a "runtime engine" to do the interpreting. What that means, of course, is that anything you write will have to be targeted at users who already have a perl interpreter installed and running, or have the smarts to follow instructions to "make it so". Not a huge drawback, but the gap between the haves and the have-nots grows wider every day!

Also, some users will expect to be able to access your program in command line mode, others will demand access via the WIMP model. Best to make 'em both happy, I should think.


On perl's regex capabilities......

Oh, yes indeed, this is one powerful puppy. Sometimes I still don't "get it". You can get lost for days trying out various possibilities, and in the end, you scratch your head and wonder if you've done it correctly after all. Sigh.


On future compatibility......

No worries about mighty MS, they don't control the HTTP protocol. Proxo will fail only if (or when) the basic nature of the HTTP protocol is so changed that everything else on the 'net also breaks at the same time. Even Uncle Bill can't engineer that to happen to his advantage. 'Nuff said.


On other people doing it......

I know an advanced programming instructor at a local community college who is doing this very thing right now, as a class exercise for his students - it's their "final exam", so to speak. Don't let this hold you back. If you do, someone else will get the glory, and that ain't a pretty thing to behold, if you get my drift! [lol]

Just an encouraging word to get you started. [rolleyes]


Oddysey

Hi Oddysey

Oddysey Wrote:No worries about mighty MS, they don't control the HTTP protocol.

My main concern is a future update/upgrade would "break" proxo. It seems MS has a problem updating their os without breaking their own programs!

About installing the perl interpreter, I was hoping to find a way around this. When I was playing around with perl, the drawback I found was I had to let my firewall [kerio 2.15] allow the interpreter to access the internet. This makes sense, but thats too broad a scope for my comfort zone.

I suppose that in the end, perl would not be suitable for this project.

Mike

Mike;

Quote:I suppose that in the end, perl would not be suitable for this project.

Au contraire, monsieur! perl would be perfect for this. Like you've already noted, there are several modules already built that handle various parts, the main thing you need to do is string them together in a cohesive fashion, give it an interface for configuration, and Voila!, you're home free.

Yeah, I make it sound simple, and if that were the case, then why hasn't anybody else already done this? Good question. I guess it's just a matter of being driven by one's need to overcome a hurdle. If the perceived gain appears to be not worth the effort to jump the hurdle, then the job won't get done, pure and simple. It's up to you to decide the benefit versus cost ratio for yourself.

The only reason I encourage you so is that you seem to have the desire to make a product that satisfies your needs, and at the same time, you want to learn several different things that you feel will be beneficial in the long run. No doubt about it, you're correct about all of that. My problem, and I suspect the same is true for many a programmer, is "where do I fit this into my already 25-hours-a-day schedule?" If time is not your biggest problem, then I say "GO FOR IT!"


On MS breaking things......

Well, yes, they do have a history of not checking their work before unleashing it on an unsuspecting public, I'll agree with that! (You'll note the I don't use my real name when I say these things - I don't want to bite the hand that fed me, and still does, in terms of my stock holdings!!)

But think for a moment..... If MS were to do anything stupid, they would be cutting themselves off from the 'net, not the other way around. I repeat, at the risk of sounding officious, they don't control the workings of the 'net. Not the protocols, not the language, not the hardware, not nada. They do act as if they did have total control, we'll agree on that, but in reality, they don't. So who does? The market place, to be sure. But that's a different subject for debate, and not germaine at this time.

Besides, if you're "this close" to foresaking Windows for *nix, then why are you worried so much? <_< In the long run, you are wise enough not to try to out-Proxo Proxo, so you won't be writing for the Windows world anyway, right? Right? Uh oh, why am I getting a bad feeling here? Mike, set me straight - what's on your mind here, buddy?


Oddysey

Hi Oddysey

As far as windows vs nix, I will probably setup a nix box in the future, just to play with. I still need windows for work, & my other family machines will remain windows based for the foreseeable future.

Oddysey Wrote:the main thing you need to do is string them together in a cohesive fashion, give it an interface for configuration, and Voila!, you're home free.

LOL, reminds me of work... "All you gotta do is ...."

The firewall issue with perl bothers me a bit, but if I remember right, privoxy has the same problem. I might still give it a whirl with perl, just for fun. Now to do decide on the "glue" to "string it together".

Since I would be working on the program on my laptop (xp) it would be nice if the program would run on it!

However, if I ever get my nix box running, I'm sure the first thing I would want to do would be to get the program running on it (assuming I ever get it done). This is why I don't want to use something like like C#.

Since I've never worked with perl before, you got any thoughts on what "glue" might make things easier?

Mike

Mike;

Quote:Since I've never worked with perl before, you got any thoughts on what "glue" might make things easier?

I'll assume you know the rudiments of programming, so I'll make further assumptions that we both define things the same way.

Perhaps you think like most "bottom-up" programmers - layout a design to meet the goal, determine where to subdivide the program flow into what sub-routines, then build and test each routine before moving on the the next piece of the puzzle. This is probably the more common method of designing and programming an application. You wind up with several sub-routines, each of which can work independently, and you then implement the master routine (the "glue") that makes them one cohesive unit.

Conversely, you can first program the master routine (ala the Visual XYZ methodology), and then build each module, testing them to make sure they work within the framework of the master routine. This is called the top-down method. Either way works well enough, it's up to the individual to use what they feel most comfortable with.

In this case, we have a bunch of sub-routines already built for us (the perl modules), so we need only build the master routine to tie them together. Chances are good that no one has put things together like this before, so we'll very likely need to write a module that allows the user to configure the rest of the package. But that can come at the tail end of the project, it's not required in order to make the application do what it's supposed to do.

I have to admit, I've not gotten out very much lately, so I'm woefully behind on what's available in the library. If you haven't checked out cpan.org lately, that's a good starting point for both learning about perl programming practices, and obtaining many different modules that have already been written and tested (or else they wouldn't be on that site). Quite a few links to other sites of interest to perl programmers, too.

All this depends, of course, on the fact that you want to learn something about programming in perl. But you really could use just about any other language to write the master routine, and simply link the perl modules in at the appropriate places in the code. That might make configuration a bit harder, but not impossible. Just implement my way of configuration - read everything from a text file. That file can be modified by the user with a text editor, or you can include an interface to do it within the application. Quick, easy, and damn near fool-proof.


Oddysey

Hi Oddysey

Well, it looks like I've got a bit of research to do. Good thing I'm not in a hurry.

It's going to take me a while to get with the basics of the language. For me, the best way to learn a new language is by jumping in & doing it. At least I've got an interesting project to work on.

By the way, I found a module at cpan, (alpha still) that sounds like the same thing we've been talking about. I didn't bookmark the link, and I'm too burned out right now to go looking for it.

Thanks
Mike

Mike;

Da nada!


Oddysey

Hi !

This header filter works ? I have checked and it has Perl command and the remote server responds by closing connection if you check the Log.

[HTTP headers]
In = TRUE
Out = TRUE
Key = "Proxy-Connection: Close all connections (in+out) {JakBeNymble}"
URL = "*"
Match = "$CON(#0-60),60[,60])"
Replace = "$CON(#0-60),60[,60])) = Close , $PORT = Close"

Please correct me, If I am wrong and where am I going wrong?

Thanks
Garcot

garcot;

Quote:This header filter works ? I have checked and it has Perl command and the remote server responds by closing connection if you check the Log.

[HTTP headers]
In = TRUE
Out = TRUE
Key = "Proxy-Connection: Close all connections (in+out) {JakBeNymble}"
URL = "*"
Match = "$CON(#0-60),60[,60])"
Replace = "$CON(#0-60),60[,60])) = Close , $PORT = Close"

I know I'm getting old, and going blind, but could you please point out to me exactly where you see any perl code in this filter? I think you'll find that the "$CON = Close" is a standard HTTP command. Likewise for the $PORT command.


Oddysey

Hi Oddysey,

Thanks for your reply. I happened to see a program coded in Perl and I saw these networks commands. $PORT is atleast not listed in the filter language at this site http://www.sankey.ws/proxfilt.html

Also please visit http://patrick.net/software/sprocket where this program is written in Perl.

I am already blind so you are better!'

Garcot

garcot;

Within Patrick K.'s code, he defines a variable named port near the very top of his program, under #default arguments. (perl uses the $ symbol to denote single variables.) So his program will simply assume Port 8080, unless a command line argument says otherwise.

If we examine the filter more closely, something I did the first time I read your post, we do indeed note that $POST is not a valid Proxo variable. However, since we're not seeing the entire configuration set, I'm gonna go out on a limb here, and predict that $PORT is defined earlier in the config. JD5000 and sidk3003 both do this, and I'm sure many other users do it too. This would explain the presence of the argument, but to put paid to the account, we need to scrutinize the filter more closely.

For now, let's pretend that $PORT has been previously defined in the config set.

Recall that the Proxo filter is both In and Out. Coming in, the $PORT argument doesn't do anything - Windows has no direct way to respond to it. Besides which, the port will close automatically, upon the connection being closed/killed. In the In scenario, the $PORT argument is a non-starter.

Now let's examing the Out side of that filter. If the server on the other end of the connection is running Apache or something similar under *nix, it will understand the argument, and obey. Hence, the server closes its port immediately, instead of waiting for a time out. Nice touch, but not really necessary. Saves maybe a few tenths of a second, one whole second at the most.

Scoreboard: ___ In ___ Out

Does it work: __ <span style='color:red'>No</span> ___ Yes, but not 100% of the time

Is it useful: ___ <span style='color:red'>No</span> ___ <span style='color:red'>No</span>

Final result _____ <span style='color:AD0008'>Bogus</span>. [beatdown]

Toss this one in the trashbin, that's my opinion. :o [lol]


Oddysey

Thanks Oddysey. With your recommendations and valuable explainations I do feel the need to trash it! I did learn a lot in the process regarding proxo programming.

Regards
Garcot