On Wed, 20 Jan 2010 10:43:19 -0300, Victor Javier Brizuela
<brizuela.victor.javier_at_gmail.com> wrote:
> Hi all,
>
> We are having a problem with Squid and a Java applet in one of our
> in-house developed application. I've gone through the FAQ and searched
> through the mailing lists but I didn't find anything to remedy the
> problem. I'm using Squid 3.0.STABLE8, the version that comes with
> Debian Lenny.
>
> The issue is with a url with a .jsp file that takes certain parameters
> and launches a Java applet to upload a file from the client computer.
> We've recently switched from a iptables-only gateway to a new gateway
> with iptables+Squid, and that's when the issue started. The Java
> version used on the client computers is 1.6.
>
> There is no authentication and squid is set to work transparently.
> I've set an iptables rule that redirets all traffic to port 80 to port
> 3128 of Squid.
>
> When someone tries to access the URL, the Java console comes up with
this
> error:
>
> cargar: clase com.zetti.web.util.FileUploader.class no encontrada.
> java.lang.ClassNotFoundException: com.zetti.web.util.FileUploader.class
> at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
> at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
> at
sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown
> Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.io.IOException: open HTTP connection
>
failed:http://ftweb-azul.zetti.com.ar/com/zetti/web/util/FileUploader/class.class
Not surprising. That URL does not exist.
I get an official 404 "Página no encontrada" response from the web server
at ftweb-azul.zetti.com.ar when I try to retrieve it manually as well.
<snip>
> 1263992243.786 12 192.168.1.33 TCP_MISS/404 1198 GET
> http://ftweb.ipg.com.ar/com/zetti/web/util/FileUploader/class.class -
> DIRECT/200.82.80.242 text/html
> 1263992246.989 12 192.168.1.33 TCP_MISS/404 910 GET
> http://ftweb.ipg.com.ar/favicon.ico - DIRECT/200.82.80.242 text/html
>
> My squid.conf is as follows:
>
> http_port 3128 transparent
Please use a random port which nobody knows. It's only relevant between
Squid and the firewall doing NAT so you can lock it down securely from
external access and avoid several major security issues.
>
> access_log /var/log/squid3/access.log squid
> cache_log /var/log/squid3/cache.log
> cache_store_log /var/log/squid3/store.log
store.log is not that useful. If you don't have a log analyzer doing
special stuff with it, you can set this to "none" and save a lot of disk
space.
>
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8
We are now recommending:
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 22 # ssh
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
>
> acl lan src 192.168.0.0/22
> acl Java browser Java/1.4 Java/1.5 Java/1.6
>
> http_access allow manager localhost
> http_access allow localhost
> http_access allow lan
> http_access allow Java
>
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>
> always_direct allow all
Prevents cache_peer being used. But then you have none anyway. This is not
worth configuring.
>
> redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
url_rewrite_program ....
>
> cache_mgr vbrizuela_at_zetti.com.ar
> visible_hostname sphinx
>
> What may I be overlooking here? Any help would be greatly appreciated.
The web server is sending Squid those error messages as far as I can tell.
>
> Thanks,
Amos
Received on Wed Jan 20 2010 - 22:34:27 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 21 2010 - 12:00:04 MST