Differences between revisions 1 and 15 (spanning 14 versions)
Revision 1 as of 2004-01-11 21:34:13
Size: 8167
Editor: anonymous
Comment:
Revision 15 as of 2019-08-15 21:28:49
Size: 4065
Editor: nodiscc
Comment: add CategoryNetwork CategorySystemAdministration
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language en
Line 2: Line 3:
O proxy Autoconfigure setup lá é diversas maneiras configurarar usuários para clientes ao autodetect um proxy. Eu vi os RFC que descrevem estes mas não mantive as ligações. Alguém satisfaz adiciona; As referências 1. de cliente moderno da correia fotorreceptora do URL de http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html Autoconfigure a maioria suportam a configuração do proxy usando um URL do autoconfigure. Este é um URL esses pontos a um Javascript simples que identifique o proxy para se usar para cada pedido. Estes podem ser completamente simples, ou surpreendente elaborados (busca para a documentação do calamar em como a carregue balencing ou hashing do URL de proxies múltiplos usando URL do autoconfigure). O cliente necessita ter o URL incorporado manualmente a sua configuração. Outras técnicas do autoconfigure são extensões justas desta para automaticly identificar o URL do autoconfigure para usar-se. Críe uma lima simples do texto que contem o certificado do autoconfigure na raiz de seu webserver. Isto pode ter o que nome você quer, mas uma convenção unofficial parece ser ' proxy.pac '. O URL do autoconfigure transforma-se então ' http://your.web.server/proxy.pac '. Um exemplo ' proxy.pac ' é::: função ["FindProxyForURL"](url, host) { se (isPlainHostName(host)||||o localHostOrDomainIs(host, "your.local.domain")) retornam" DIRIGEM "; retorne o "PROXY your.proxy.server:8080; DIRIJA "; } isto diz o web browser para ir direto para nomes de anfitrião lisos ou para anfitriões ' em your.local.domain ', se não em uso ' your.proxy.server ', caindo para trás para dirigir se estiver para baixo. O URL deve ser servido acima com um tipo particular do MIME, mas eu não sou certo o que o RFC especifica, ou quantos clientes se importam actualy com este. O tipo do MIME de Debian do defeito de limas do pac é ' application/x-ns-proxy-autoconfig ', e este é o que apache lhe serve acima como. Autodetection baseado DNS eu esqueço-me dos detalhes exatos, mas um método automaticlly de identificar o URL do autoconfigure deve usar um nome do DNS e um URL especiais para seu domínio. Algum RFC ou outro especificam um URL no formulário ' http://wpad.your.local.domain/wpad.dat '. Anote o nome da lima é diferente ao padrão do defacto ' de proxy.pac '. A solução simples para esta deve fazer ' a wpad.your.local.domain ' um CNAME a seu webserver e pôr um symlink ' wpad.dat ' que aponta ' em proxy.pac ' em sua raiz do website. Anote que Debian não tem o tipo apropriado do MIME para a lima de proxy.dat, assim que apache servirá a este acima como ' text/plain '. Isto é signifiquant a alguns browsers, mas não a algum outro. Você necessita configurarar Apache para forçar o tipo correto do MIME sem decidir-se que todas as limas do dat são para a configuração do proxy. O truque deve ajustar acima um anfitrião virtual em apache como wpad.your.local.domain, e adicionar o tipo do MIME dentro da diretriz orientadora virtual do anfitrião. DHCP baseou o autodetection que eu não sou certo se for o mesmo RFC, mas o URL do autoconfigure pode também ser entregado aos clientes por DHCP. Eu penso que o IE é atualmente o único cliente que suporta este. Para fazer isto, ponha o seguinte no seu '/etc/dhcpd.conf '::: # isto é o autoconfig do proxy do wpad que ajusta a opção option-252 "http://your.web.server/proxy.pac"; Eu não posso ajudar mas sentir que DHCP é assim que amarrado à iniciação da rede do nível do OS que os clientes que funcionam apenas no alto de um OS nunca usarão este. Somente clientes que são integrados firmemente com o OS como IE/win32 poderá fazer exame da vantagem dele. < b>DonovanBaarda, 2003/04/16 de UTC de 11:03 (através de web):</b><br > I pensou que eu escrevi algo neste em algum lugar... Agora o google deve poder encontrá-lo demasiado com meu nome nele mim Da3m0n
Line 4: Line 4:
<b>2003/05/14 19:19 UTC (via web):</b>----
Thanks for the translation work, but did you have to trash the original english version? I don't have a copy of it.. can we revive the original version?
== Proxy Autoconfigure Setup ==
Line 7: Line 6:
Proxy Autoconfigure setup is diverse ways there to configurarar using for customers to autodetect one proxy. I saw the RFC that describes these but I did not keep the linkings. Somebody satisfies adds; References 1. of modern customer of the fotorreceptora leather strap of the URL of http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html Autoconfigure the majority supports the configuration of proxy using a URL of autoconfigure. This is a URL these points to a simple Javascript that identifies proxy to use itself for each order. These can completely simple, or surprising be elaborated (balencing or hashing of the multiple URL of proxies searchs for the documentation of the squid in as carregue using URL of autoconfigure). The customer needs to have the incorporated URL manually its configuration. Others techniques of autoconfigure are extensions jousts of this for automaticly to identify the URL of autoconfigure to use itself. Críe one rasps simple of the text that will count the certificate of autoconfigure in the root of its webserver. This can have what name you want, but a unofficial convention seems to be proxy.pac. The URL of autoconfigure changeds then http://your.web.server/proxy.pac. An example proxy.pac is::: ["FindProxyForURL"]?(url function, host) { if (isPlainHostName(host)||||o localHostOrDomainIs(host, "your.local.domain")) returns" DIRIGEM "; your.proxy.server:8080 returns the "PROXY; IT DIRECTS "; } this says the web browser to go direct for smooth names of host or hosts in your.local.domain, if in use not to your.proxy.server, falling stops backwards directing will be for low. The URL must be served above with a particular type of the MIME, but I am not certain what the RFC specifies, or how many customers if import actualy with this. The type of the MIME of Debian of the defect of rasps of the CAP is application/x-ns-proxy-autoconfig, and this is what apache it serves to it above as. Established Autodetection DNS I forget them accurate details, but a method automaticlly to identify the URL of autoconfigure must use a name of the special DNS and a URL for its domain. Some RFC or another one specifies a URL in the form http://wpad.your.local.domain/wpad.dat. It writes down the name of the rasp is different to the standard of defacto of proxy.pac. The simple solution for this must make wpad.your.local.domain a CNAME its to webserver and to put one symlink wpad.dat that it points in proxy.pac in its root of the website. It writes down that Debian does not have the appropriate type of the MIME for the rasp of proxy.dat, that thus apache will serve above to this as text/plain. That is signifiquant to some browsers, but not to some another one. You need to configurarar Apache to force the correct type of the MIME without deciding itself that all the rasps of dat are for the configuration of proxy. The trick must above adjust a virtual host in apache as wpad.your.local.domain, and inside add the type of the MIME of the virtual orienting line of direction of the host. DHCP based autodetection that I am not certain I will be myself the same RFC, but the URL of autoconfigure can also be delivered to the customers for DHCP. I thinks that the IE is currently the only customer who supports this. To make this, it puts following in its '/etc/dhcpd.conf '::: # that is autoconfig of proxy of wpad that it adjusts to the option option-252 "http://your.web.server/proxy.pac"; I cannot help but to feel that DHCP thus that is moored to the initiation of the net of the level of the THE ONES that the customers who never function only in the high one of one they will use this. Customers who are integrated firmly with as IE/win32 will only be able to make examination of the advantage undo < b>DonovanBaarda, 2003/04/16 of 11:03 UTC (through web): I thought that I wrote something in this in some place... Now google must be able to too much find it with my name in it me Da3m0n
Thank You Mister BabbleFish..:-)
There are several ways to configure servers for clients to autodetect a proxy. I have seen RFC's that describe these but didn't keep links. Someone please add;

The WPAD-standard is described in an internet-draft available at
http://www.web-cache.com/Writings/Internet-Drafts/draft-ietf-wrec-wpad-01.txt

=== References ===

1. http://web.archive.org/web/20060424005037/wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

=== Autoconfigure URL ===

Most modern web clients support proxy configuration using an autoconfigure URL. This is a url that points to a simple javascript that identifies the proxy to use for each request. These can be quite simple, or amazingly elaborate (search for Squid documentation on how to do load balencing or URL hashing of multiple proxies using autoconfigure URL's). The client needs to have the URL manually entered in its configuration. Other autoconfigure techniques are just extensions of this for automaticly identifying the autoconfigure URL to use.

Create a simple text file containing the autoconfigure script in the root of your webserver. This can have whatever name you want, but an unofficial convention seems to be proxy.pac. The autoconfigure url then becomes http://your.web.server/proxy.pac. An example proxy.pac is:
{{{
    function ["FindProxyForURL"](url,host)
    {
        if ( isPlainHostName(host) |||| localHostOrDomainIs(host, "your.local.domain") )
            return "DIRECT";
        return "PROXY your.proxy.server:8080; DIRECT";
    }
}}}


This tells the web browser to go direct for plain host names or for hosts in your.local.domain, otherwise use your.proxy.server, falling back to direct if it is down.

The URL should be served up with a particular mime type, but I'm not sure what the RFC specifies, or how many clients actualy care about this. The default Debian mime type of .pac files is application/x-ns-proxy-autoconfig, and this is what apache serves it up as.

=== DNS based autodetection ===

I forget the exact details, but one method of automaticlly identifying the autoconfigure URL is to use a special DNS name and URL for your domain. Some RFC or other specifies a URL in the form http://wpad.your.local.domain/wpad.dat. Note the file name is different to the defacto standard of proxy.pac. The simple solution for this is to make wpad.your.local.domain a CNAME to your webserver and put a symlink wpad.dat pointing at proxy.pac in your website root.

Note that Debian does not have the appropriate mime type for the proxy.dat file, so apache will serve this up as text/plain. This is signifigant to some browsers, but not to some others. You need to configure Apache to force the correct mime type without deciding that all .dat files are for proxy configuration. The trick is to set up a virtual host in apache like wpad.your.local.domain, and to add the mime type within the virtual host directive.

=== DHCP based autodetection ===

I'm not sure if it's the same RFC, but the autoconfigure URL can also be delivered to clients by DHCP. I think IE is currently the only client that supports this. To do this, put the following in your /etc/dhcp3/dhcpd.conf:
{{{
    option wpad-url code 252 = text;
    option wpad-url "http://your.web.server/proxy.pac\n";
}}}

The trailing newline is included to compensate for IE 6.01's stripping of the last character.

I can't help but feel that DHCP is so tied to OS level network initialisation that clients that just run on top of an OS will never use this. Only clients that are tightly integrated with the OS like IE/win32 will be able to take advantage of it.

== Warning ==
There is a bug in Firefox that makes the GUI hang during PAC/DNS lookup. This is quite annoying. I think that Comment #43 on https://bugzilla.mozilla.org/show_bug.cgi?id=235853 has a valuable solution to write the pac file the right way!

-------

CategoryNetwork CategorySystemAdministration

Proxy Autoconfigure Setup

There are several ways to configure servers for clients to autodetect a proxy. I have seen RFC's that describe these but didn't keep links. Someone please add;

The WPAD-standard is described in an internet-draft available at http://www.web-cache.com/Writings/Internet-Drafts/draft-ietf-wrec-wpad-01.txt

References

1. http://web.archive.org/web/20060424005037/wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

Autoconfigure URL

Most modern web clients support proxy configuration using an autoconfigure URL. This is a url that points to a simple javascript that identifies the proxy to use for each request. These can be quite simple, or amazingly elaborate (search for Squid documentation on how to do load balencing or URL hashing of multiple proxies using autoconfigure URL's). The client needs to have the URL manually entered in its configuration. Other autoconfigure techniques are just extensions of this for automaticly identifying the autoconfigure URL to use.

Create a simple text file containing the autoconfigure script in the root of your webserver. This can have whatever name you want, but an unofficial convention seems to be proxy.pac. The autoconfigure url then becomes http://your.web.server/proxy.pac. An example proxy.pac is:

    function ["FindProxyForURL"](url,host)
    {
        if ( isPlainHostName(host) |||| localHostOrDomainIs(host, "your.local.domain") )
            return "DIRECT";
        return "PROXY your.proxy.server:8080; DIRECT";
    }

This tells the web browser to go direct for plain host names or for hosts in your.local.domain, otherwise use your.proxy.server, falling back to direct if it is down.

The URL should be served up with a particular mime type, but I'm not sure what the RFC specifies, or how many clients actualy care about this. The default Debian mime type of .pac files is application/x-ns-proxy-autoconfig, and this is what apache serves it up as.

DNS based autodetection

I forget the exact details, but one method of automaticlly identifying the autoconfigure URL is to use a special DNS name and URL for your domain. Some RFC or other specifies a URL in the form http://wpad.your.local.domain/wpad.dat. Note the file name is different to the defacto standard of proxy.pac. The simple solution for this is to make wpad.your.local.domain a CNAME to your webserver and put a symlink wpad.dat pointing at proxy.pac in your website root.

Note that Debian does not have the appropriate mime type for the proxy.dat file, so apache will serve this up as text/plain. This is signifigant to some browsers, but not to some others. You need to configure Apache to force the correct mime type without deciding that all .dat files are for proxy configuration. The trick is to set up a virtual host in apache like wpad.your.local.domain, and to add the mime type within the virtual host directive.

DHCP based autodetection

I'm not sure if it's the same RFC, but the autoconfigure URL can also be delivered to clients by DHCP. I think IE is currently the only client that supports this. To do this, put the following in your /etc/dhcp3/dhcpd.conf:

    option wpad-url code 252 = text;
    option wpad-url "http://your.web.server/proxy.pac\n";

The trailing newline is included to compensate for IE 6.01's stripping of the last character.

I can't help but feel that DHCP is so tied to OS level network initialisation that clients that just run on top of an OS will never use this. Only clients that are tightly integrated with the OS like IE/win32 will be able to take advantage of it.

Warning

There is a bug in Firefox that makes the GUI hang during PAC/DNS lookup. This is quite annoying. I think that Comment #43 on https://bugzilla.mozilla.org/show_bug.cgi?id=235853 has a valuable solution to write the pac file the right way!


CategoryNetwork CategorySystemAdministration