Menu
▾
▴
Re: [proxyTools-users] escaping a very restrictive
|
From: wayne <wa...@ny...> - 2002-10-15 21:18:14
|
> From: Michael Foord <Mic...@tb...> > To: "pro...@li..." <pro...@li...> > Subject: Re: [proxyTools-users] escaping a very restrictive > > > [...] > > > Got this result - this make more sense ?? Still looks odd to me..... > > > > > > C:\Program Files\localproxy>perl statproxy.pl -t all -a ,192.168.4.1,michael,****** > > > 192.168.4.1:8080 > > > > > > statProxy v4.105 report from 192.168.4.67: > > > 192.168.4.1 :8080 AFFFFFFFFFFFF FFFFF 0.0/? > > > > This is the right proxy, at least. You got a response this time. > > The first test shows 'A'uthentication was required (and it failed). > > The rest failed for the same reason. > > I hope you tell me that you just entered the wrong password. :-) > > Did you have the credentials correct in the environment too > > (shouldn't be needed, but if there's a conflict you might have > > triggered a new bug)? > > > > Again, I don't think I have changed anything that should affect the > > authentication. Do you still have the old statProxy? Does that one > > work? > > > > > Mike > > > > Nope double checked the password. > > First the current version of statprox - still fails. > > C:\Program Files\localproxy>perl statproxy.pl -t all -a ,192.168.4.1,michael,****** > 192.168.4.1:8080 > > statProxy v4.105 report from 192.168.4.67: > 192.168.4.1 :8080 AFFFFFFFFFFFF FFFFF 0.1/? Maybe the syntax *is* wrong after all. My documentation says to use -a ,192.168.4.1:8080,michael,****** and I think I insisted on that port in there for security reasons. Can't test right now, but see if that changes anything. > Then an old version. > > C:\Program Files\localproxy>oldstatprox > > C:\Program Files\localproxy>perl oldstatproxy.pl -t all -a ,192.168.4.1,michael, > ****** 192.168.4.1:8080 > "nonBlockingConnect" is not exported by the WLib module at oldstatproxy.pl line > 28 > Can't continue after import errors at oldstatproxy.pl line 28 > BEGIN failed--compilation aborted at oldstatproxy.pl line 30. > > C:\Program Files\localproxy> > > > Must be a *dud* old version of statproxy so I reused one from the 2002-06-14 distribution of > proxytools. It needs a corresponding version of the library WLib.pm. > Same error, maybe that was that version I was using. > Try 2002-08-02. > > Nope... still the same result - Wlib.pm has changed I guess - one last try > 2002-09-04 which was the previous version I guess (wasn`t that bugged ??) > > C:\Program Files\localproxy>perl oldstatproxy.pl -t all -a ,192.168.4.1,michael, > ****** 192.168.4.1:8080 > > statProxy v4.95 report from 192.168.4.67: > 192.168.4.1 :8080 AFFFFFFFFFFFF FFFFsend() on closed socket PROXY at oldsta > tproxy.pl line 1016. > Your vendor has not defined POSIX macro EWOULDBLOCK, used at oldstatproxy.pl lin > e 1017 > > C:\Program Files\localproxy> > > Yup - thats the old error isn`t it ?? > > So not much luck on testing with an old version of statproxy. Now I could use an old entire > distribution... bugger, I`ll try that. That's really the only sure way. > C:\Program Files\localproxy>cd .. > > C:\Program Files>cd lp.bak > > C:\Program Files\lp.bak>statprox > > C:\Program Files\lp.bak>perl statproxy.pl -t all -a ,192.168.4.1,michael,****** > 192.168.4.1:8080 > > statProxy v4.91 report from 192.168.4.67: > 192.168.4.1 :8080 AFFFFFFFFFFFF FFFFF 1.9/? > Reference page size was 534 bytes > > > C:\Program Files\lp.bak> > > OK - same result (but done a lot slower) using the August distribution (08 !!). Yep. I improved the speed some with new socket code, and reduced a timeout or two, IIRC. > So it looks like something has changed on my system as this used to work - damn. Or your syntax changed :-) > Hmmm - better check my environment variables and check they are set up right and ping dav-serv > to make sure it hasn`t changed - our `system` is in a constant state of flux so nothing can be > relied on. > > Ping dav-serv = 192.168.4.1 > > Environment variables : > > SET HTTP_proxy=http://192.168.4.1:8080 > SET HTTP_proxy_user=michael > SET HTTP_proxy_pass=****** > SET HTTP_proxy_realm=dav-serv.tbsmerchants.co.uk > > looks alright to me.... > > Note that the `rules` for the Superscout proxy server have changed and it is now much stricter > as to what it is supposed to allow (although as noted some ports now appear to be open!!). > > In theory that *shouldn`t* affect basic authentication though - unless statproxy.pl is trying > to conenct to a specific site (previously unblocked) and the `blocked` error it now thinks of > as an authentication failure ?? No. Test 0 is requiring authentication, and the credentials are not found or are failing. > Hmmm... looking through and seeing if theres anything else I can do to provide useful > information - guess I`ll run localproxy with debug=3 and see what it says when trying to > connect - see if it reports authentication errors or just the usual problems of trying to find > a proxy it can reach. As far as I can remember if I point IE to localhost:10080 with lp > running the error is Superscout Blocked *NOT* authentication failed which would indicate to me > that lp is passing on the authentications trings from the environment/config fine... but its > worth double checking. If you still see that with localProxy, bump up the debug to 4 for a few requests. that will show the details of the authentication request. > Mike -- wa...@ny... http://proxytools.sourceforge.net/ > From: Michael Foord <Mic...@tb...> > To: "pro...@li..." <pro...@li...> > Subject: [proxyTools-users] Testing Localproxy > > Despite problems with statproxy have tested localproxy. Unless you get that authentication working, LP will not work. SP is the simplest test for it. > Following are the tests and logs (basically for Wayne - not of much > interest to anyone else I`m afraid - > sorry). > > In summary - the new cgi options seem to work fine without me having to > do anything babelfish.altavista must > be unblocked. Unfortuantely it does text only not images Heh, thanks - it redirects your browser to them. Coulda sworn the Google translation (where I did most of the testing) sent the images back too. Oh well, they're not real good CGIs anyway (you should use your own in the cgiAmbles.txt file). Remember, that's just commStrat 2g. There are several other commStrat 2 substrats, as well as commStrats 0 (useless for you unless there are some proxies on 25, or 110), and commStrat 1 (which was the way we got it to work for you before). > so restricts my > browsing some what. I need to > modify the entries for either google of for my own cgi proxy which I > ought to be able to use. Yep. > Need to know how to disable it - just rem out the valid option in > cgiambles.txt I guess - how about a button > on the GUI !!! You can disable the whole of commStrat 2 there. There's now way to disable the substrats it's using from the GUI though - yet. I'm waiting for feedback like yours to decide how best to handle it. > Also it looks like localproxy uses babelfish *even* when > it can get straight through which > seems a waste..... It's the design philosophy. It *must* try everything before it can decide what's working, what's fastest, etc. And a single failure doesn't prove much (especially in the kind of crappy environment LP is used in), so it must try several times, and then occasionally in the future as well. > hmmm... just thought - some of the images (in the > title bar) came through babelfish for > google.com - odd, now I`m completely baffled. Babelfish redirects your browser to the real image URL. Your browser then requests it via LP. LP is likely to use another strategy which works. All part of the learning process ... > Anyway - following are the logs - but not too useful now I guess as I > was just feeling my way and they don`t > really say anything more than the above !! [...] > Disabling 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 > hosts avail > able > - > Filled layer 10080.0.*.- (0/10) > > Disabling 10080 (non-censoring HTTP proxy - standard).0 - no layer 0 > hosts avail > able > Filled layer 10080.1.*.- (1/10) This one would be your firewall proxy. LP has info that it can CONNECT from your config file. > Filled layer 10080.1.-.* (0/10) > > Disabling 10080 (non-censoring HTTP proxy - standard).1 - no layer 1 > hosts avail > able **************************** This is your biggest problem. LP will not even attempt to use your proxy with commStrat 1 (CONNECT) - the way we had it working before. Why? Have you merged those bad statProxy results into your config? Or did you get that to work (show me the results please)? From the logs below, I see there is still a problem related to the 'fix' I mentioned recently (the one I said was worth getting). Were you using a *very* recent localProxy2.pl (less than 36 hours)? CommStrat 2 will work eventually (and probably be fast) with that fix (although I might still need to tweak it). But commStrat 1 will always be more reliable. **************************** > Filled layer 10080.2.*.- (1/10) Some of the previous commStrat 2 tests showed your own proxy to be vulnerable, so it's used here too. > Filled layer 10082.0.*.- (0/10) > [...] > Filled layer 10076.0.*.- (1/10) > - > Disabling 11080 (Socks 4 - standard).1 - no layer 1 hosts available Huh? No log for 11080.0? How is this service specified in your config? It's not in the copy I have. > Filled layer 11080.2.*.- (0/10) > > Disabling 11080 (Socks 4 - standard).2 - no layer 0 hosts available > Checking all layer 0 hosts for connectivity... > Running initial Layer0 check ... > .. online [...] > And front end..... [...] > Checked under authentication - credentials correct as far as I can see > > Known credentials: > ,,dav-serv.tbsmerchants.co.uk,192.168.4.1:8080,michael,****** > ,,dav-serv.tbsmerchants.co.uk,192.168.4.1:8080,michael,****** Hmm .. from your environment, or your config? SP only uses the environment so far ... must fix that. > Pending requests (edit username and password): > None > > Right now point my browser to localhost 10080 > > Straightforward access to google (which isn`t blocked). > Seems to go via a complicated route !! (can see babelfish popping up a > couple of times - must play with > those cgi options..) but works. It should eventually learn the best way, but note that it will never use commStrat 0 via your proxy directly because that possibility was killed right back at the build (your proxy is damaged, it censors, so LP doesn't include it in the list to try directly - commStrat 0). It will try using commStrat 2 (encoded URLs). Because of the randomness in choosing which substrats to try, one 'substrat' will have *no* substrats (the URL goes unencoded). This would be the same as commStrat 0. The biggest problem with commStrat 2 is the number of combined substrats LP wants to try - lotsa failures until it learns. I'm working on it ... Whether CommStrat 2 works depends more on the site than on the proxy(ies) LP is using, so even when it learns, if you change sites you might see failures again. The commStrat 2 approach will never be 100%. It's a limitation in the idea itself. Very fast when it works though ... > Sent credentials (michael:******) to 192.168.4.1:8080 as auth-scheme > Basic > 10080.2.0.-: 1.9e+003:1.9e+003 (1.9e+003(80.2)) (1.9e+003) > 1.9e+003(=0.951/0.000 > 5) > Original request: GET http://www.google.com/ HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://www.goo > gle.com/&lp=ja_en HTTP/1.0 > 10080.2.0.-: 1.5:1.5 (1.5(80.2)) (1.4) 1.3(=6.13/4.83) > Original request: GET > http://216.239.53.102/search?client=navclient-auto&ch=5455 > 726090&features=Rank&q=info:http%3A%2F%2Fwww%2Egoogle%2Ecom%2F HTTP/1.0 > access denied or failed from 10080.2(1).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > 10080.2.0.-: 1.6:1.5 (1.3(80.2)) (0.94) 1.1e+003(=0.544/0.0005) > Original request: GET http://babel.altavista.com/aftu HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://babel.a > ltavista.com/%61%66%74%75&lp=ja_en HTTP/1.0 > Original request: GET http://www.google.com/images/hp0.gif HTTP/1.0 > Modified request: GET > http://www.google.com/%69%6d%61%67%65%73/%68%70%30%2e%67%6 > 9%66 HTTP/1.0 > Original request: GET http://www.google.com/images/hp1.gif HTTP/1.0 > Original request: GET http://www.google.com/images/hp2.gif HTTP/1.0 > 10080.2.0.-: 2.1:2 (1.8(80.2)) (1.4) 27(=2.93/0.11) > 10080.2.0.-: 2.7:2.6 (2.4(80.2)) (2) 20(=3.18/0.16) > Original request: GET http://www.google.com/images/hp3.gif HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://www.goo > gle.com/%69%6d%61%67%65%73/%68%70%33%2e%67%69%66&lp=ja_en HTTP/1.0 > Original request: GET http://www.google.com/images/hp3.gif HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://www.goo > gle.com/%69%6d%61%67%65%73/%68%70%33%2e%67%69%66&lp=ja_en HTTP/1.0 > 10080.2.0.-: 2:1.9 (1.8(80.2)) (1.4) 1.1(=4.5/4.17) > 10080.2.0.-: 1.1:1 (0.96(80.2)) (0.68) 0.047(=0.374/8.02) > 10080.2.0.-: 0.33:0.31 (0.3(80.2)) (0.18) 0.0095(=0.368/38.8) > > > Looks to me like its going via babelfish !! Lots of Japanese characters > appearing on my google screen !!! Hmmm ... maybe you ended up at a Japanese Google. Click the 'English' link, if it's there. Those characters should have been translated by Babelfish anyway (???). > But > at least localproxy is working !! Doesn`t it check whether it can go > `direct` (well via superscout anyway) > before it chooses to use the babelfish option ?? (Don`t mean to sound > ungrateful - heck if it works it works !! It 'checks' randomly (commStrat 2 with no substrats), but only as one of the many options to try. You only have one proxy it can use, at least, but there are still 5x4x3x2x1 options! > Itsjust that if this stops it trying alternative means how do I disable > it!!) At the moment all you can do is disable commStrat 2 entirely. I'm still trying to come up with a reasonable way to do this for the user automatically; I don't think there is a 100% way. You can always disable just 2g at build time, of course (in commStrats.xml, or by adding an overload of this in your config). The GUI would be the best way, I guess - will look at adding that. > Ought to work for anything now though - lets try something blocked. > > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://comics. > com/&lp=ja_en HTTP/1.0 > Original request: GET > http://216.239.35.102/search?client=navclient-auto&failedi > p=216.239.37.102;130&ch=51374619684&features=Rank&q=info:http%3A%2F%2Fcomics%2Ec > > om%2F HTTP/1.0 > access denied or failed from 10080.2(1).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > 10080.2.0.-: 0.45:0.23 (0.029(80.2)) (0.00083) 1.1e+003(=0.544/0.0005) > Original request: GET http://babel.altavista.com/aftu HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://babel.a > ltavista.com/%61%66%74%75&lp=ja_en HTTP/1.0 > Original request: GET > http://216.239.35.102/search?client=navclient-auto&failedi > p=216.239.35.102;6542&ch=51374619684&features=Rank&q=info:http%3A%2F%2Fcomics%2E > > com%2F HTTP/1.0 > access denied or failed from 10080.2(1).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > 10080.2.0.-: 0.46:0.23 (0.024(80.2)) (0.00054) 1.1e+003(=0.544/0.0005) > Original request: GET > http://comics.com/images/comics_com_logo_top_green.gif HTT > P/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://comics. > com/%69%6d%61%67%65%73/%63%6f%6d%69%63%73_%63%6f%6d_%6c%6f%67%6f_%74%6f%70_%67%7 > > 2%65%65%6e%2e%67%69%66&lp=ja_en HTTP/1.0 > Original request: GET http://comics.com/images/comics_com_logo_combo.gif > HTTP/1. > 0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://65.114. > 4.69/images/comics_com_logo_combo.gif&lp=ja_en HTTP/1.0 > > > Comics.com - blocked at first, then it works.... hurrah. Also implying > that it does try via superscout first !!! Yes, but only with commStrat 2 (see above). The bad news is there are too many options to try, so the learning process is too long. If you tried for longer on each of these sites, it would probably get them 99% of the time eventually. > Hmmmm... odd seeing as google.com would work. > > Wonder why its working now when it wasn`t yesterday !! Far out. It's all randomness. If LP gets into a hole in the early stages, it can take a long time to crawl out. Learning is a bugger like that. I'm sure I can improve the algo, but it's difficult. > Slow > though especially on images which > for the most part don`t load - not down to localproxy or babelfish > though is either superscout or our ISP > (pipex) although is very bad on this test - not getting *any* images > from comics.com or dilbert.com . If you can get your own cgi in cgiAmbles.txt, you should get more reliable results (though maybe slower than one of the translators which will pass images back to you rather than redirect). > Hmmmmm........ Not working at all now - odd comics.com is blocked - why > should it get through to that but > not > http://65.114.4.69/comics/dilbert/archive/images/dilbert2036575021015.gif > > Which is the image and is coming up `blocked arts and entertainments` > (perhaps superscout blocks .gif files > from babelfish.... oddness) The randomness again. Those images are each a new request to LP (new commStrat, new substrat, new proxies chosen). > following are some logs.... > > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://65.114. > 4.69/comics/dilbert/archive/images/dilbert2036575021015.gif&lp=ja_en > HTTP/1.0 > 10080.2.0.-: 0.62:0.1 (0.19(80.2)) (0.066) 0.095(=0.412/4.34) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://65.114. > 4.69/%63%6f%6d%69%63%73/%64%69%6c%62%65%72%74/%61%72%63%68%69%76%65/%69%6d%61%67 > > %65%73/%64%69%6c%62%65%72%74%32%30%33%36%35%37%35%30%32%31%30%31%35%2e%67%69%66& > > lp=ja_en HTTP/1.0 > 10080.2.0.-: 0.6:0.12 (0.28(80.2)) (0.085) 0.097(=0.412/4.23) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.61:0.12 (0.23(80.2)) (0.057) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.61:0.11 (0.18(80.2)) (0.038) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.62:0.11 (0.15(80.2)) (0.025) 9(=0.541/0.06) > > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.77:0.061 (0.12(80.2)) (0.033) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.78:0.058 (0.096(80.2)) (0.022) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.79:0.056 (0.078(80.2)) (0.015) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.8:0.054 (0.064(80.2)) (0.0097) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.8:0.051 (0.052(80.2)) (0.0065) 1.1e+003(=0.541/0.0005) > Original request: GET > http://65.114.4.69/comics/dilbert/archive/images/dilbert20 > 36575021015.gif HTTP/1.0 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 0.81:0.049 (0.043(80.2)) (0.0043) 1.1e+003(=0.541/0.0005) > O > > > > > Try another URl - sex.com for arguments sake... > > 2Ecom%2F HTTP/1.0 > Original request: GET http://www.sex.com/ HTTP/1.0 > access denied or failed from 10080.2(7).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > access denied or failed from 10080.2.0(192.168.4.1:8080).-(-): HTTP/1.1 > 403 > 10080.2.0.-: 1.1:0.09 (0.074(80.2)) (0.0032) 11(=0.544/0.05) > 10080.2.0.-: 1.1:0.086 (0.06(80.2)) (0.0022) 1.1e+003(=0.544/0.0005) > Original request: GET > http://216.239.33.102/search?client=navclient-auto&failedi > p=216.239.33.102;349&ch=53435104105&features=Rank&q=info:http%3A%2F%2Fwww%2Esex% > > 2Ecom%2F HTTP/1.0 > access denied or failed from 10080.2(7).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > 10080.2.0.-: 1.1:0.083 (0.049(80.2)) (0.0014) 1.1e+003(=0.544/0.0005) > Original request: GET http://www.sex.com/ HTTP/1.0 > Modified request: GET > http://babelfish.altavista.com/urltrurl?url=http://www.sex > .com/&lp=ja_en HTTP/1.0 > Original request: GET http://babel.altavista.com/aftu HTTP/1.0 > Modified request: GET http://209.73.180.18/%61%66%74%75 HTTP/1.0 > Original request: GET > http://216.239.53.102/search?client=navclient-auto&failedi > p=216.239.33.102;11120&ch=53435104105&features=Rank&q=info:http%3A%2F%2Fwww%2Ese > > x%2Ecom%2F HTTP/1.0 > access denied or failed from 10080.2(a71).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > > access denied or failed from 10080.2(a1).0(192.168.4.1:8080).-(-): > HTTP/1.1 403 > 10080.2.0.-: 1.1:0.079 (0.04(80.2)) (0.00094) 11(=0.535/0.05) > 10080.2.0.-: 1.1:0.076 (0.033(80.2)) (0.00063) 1.1e+003(=0.544/0.0005) > > Fails at first and then gets through.... no images - images must be > blocked from babelfish. Well, it sends back a redirect to your browser which tries again via LP. > Mike -- wa...@ny... http://proxytools.sourceforge.net/ > From: Michael Foord <Mic...@tb...> > To: "pro...@li..." <pro...@li...> > Subject: [proxyTools-users] More Fiddling With CGI [now is error detected] > > My cgi proxy is the James Marshalls one > > This is my CGIAmbles.txt > > #Format of entries: firewall, preamble, postamble > #localProxy will request $preamble.escaped($url).$postamble > #Use the first line that matches our firewall, or use '*' (all > firewalls). > #*, https://vip.megaproxy.com/go/, > #*, http://web.archive.org/, > #*, http://216.239.35.120/translate_c?&langpair=en%7Cen&u=, > #XXX - note the hard-coded spanish to english conversion here. > #XXX - This gets english pages,but some english words look like > #XXX - spanish and get translated (e.g. 'can' changes to 'dog' :-) > #*, http://babelfish.altavista.com/urltrurl?url=, &lp=es_en > #XXX - We should probably check > #XXX - the user's system to see if he's probably looking for > #XXX - pages in the chosen lang here, and choose some other conversion! > #Use Japanese (ja) (or chinese (zn)), low chance of accidental > collisions > #Note: translation ends at this: <blink>*** TRANSLATION ENDS HERE > ***</blink> > #*, http://babelfish.altavista.com/urltrurl?url=, &lp=ja_en > *.http://******.com/cgiproxy/nph-proxy.pl/000100A/http/ > > It expects the URL to be minus the http:// - I`ll try changing that last > entry to > > *.http://******.com/cgiproxy/nph-proxy.pl/000100A/ > > and see if it works better ..... > > Am I doing this right ? No. You need a comma, not a dot after the *. And the format has a comma at the end too (but I think I already allowed for that mistake). Make sure the line at the end has a new-line on the end of it too (enter), although I think it would be ok without too. I hadn't tested with a Junkbuster. OK. Now I've changed the format used in this file (and LP2 to handle that). There's another field on the end which specifies to remove stuff from the URL. The new file has an example for (my) cgi proxy at the end. Yours looks a bit different, but I think you can see how it works. If yours works, leave it. Remember the removal code only works with the new localProxy2.pl. > As a `quick fix` for getting up and running this is great Wayne. Sorry commStrat 2 is still so unreliable. You need your commStrat 1 working. > Oops just spotted *.http://etc should be *, http://etc, which might help > - will try again and repost result - the URL format is still slightly > different though. > > Mike -- wa...@ny... http://proxytools.sourceforge.net/ |
