Hi,
Look at this bug:
http://bugs.squid-cache.org/show_bug.cgi?id=3141
Likely it's the same problem.
I hope that it will be fixed in the incoming 3.2.
Regards
Guido Serassio
Acme Consulting S.r.l.
Microsoft Silver Certified Partner
VMware Professional Partner
Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135 Fax. : +39.011.9781115
Email: guido.serassio_at_acmeconsulting.it
WWW: http://www.acmeconsulting.it
> -----Messaggio originale-----
> Da: kimi ge(����) [mailto:weijunge_at_gmail.com]
> Inviato: mercoled�� 11 gennaio 2012 8.47
> A: Amos Jeffries
> Cc: squid-users_at_squid-cache.org
> Oggetto: Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
>
> Thanks Amos.
>
> I did the lynx test on back-end web site on squid system like this:
> sudo lynx http://wtestsm1.asiapacific.hpqcorp.net
>
> First, it show the message:
> Alert!: Invalid header 'WWW-Authenticate: NTLM'
>
> Then it show the following message.
> Show the 401 message body? (y/n)
>
> For the domain auth, I mean the back-end web site need corp domain
> user to be accessed.
> I put this in this way, if I log on with my corp domain on my laptop,
> then I could acces IIS Share Point without any credentials window pop
> up. If not, I have to input my domain account on credentials window to
> access the Share Point Site.
>
>
> The following is my squid configuration about this case which I ignore
> some default sections.
> #added by kimi
> acl hpnet src 16.0.0.0/8 # RFC1918 possible internal network
> #added by kimi
> acl origin_servers dstdomain ids-ams.elabs.eds.com
> http_access allow origin_servers
> http_access allow hpnet
>
> http_port 192.85.142.88:80 accel defaultsite=ids-ams.elabs.eds.com
> connection-auth=on
>
> forwarded_for on
>
> request_header_access WWW-Authenticate allow all
>
> cache_peer wtestsm1.asiapacific.hpqcorp.net parent 80 0 no-query
> no-digest originserver name=main connection-auth=on login=PASS
>
> cache_peer_domain main .elabs.eds.com
>
> hierarchy_stoplist cgi-bin ?
>
> coredump_dir /var/spool/squid
>
> # Add any of your own refresh_pattern entries above these.
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> cache_dir aufs /data/squid/cache 12000 64 256
> cache_mem 1024 MB
> maximum_object_size_in_memory 1024 KB
> maximum_object_size 51200 KB
>
> visible_hostname ids-ams.elabs.eds.com
> debug_options ALL,5
> http_access deny all
>
> While let squid be running, I do test like this
> http://ids-ams.elabs.eds.com
>
> The 404 error page is shown.
> That's why I am wondering squid could be as reverse-proxy with IIS
> SharePoint as back-end?
>
> Thanks,
> ~Kimi
>
>
>
> On 11/01/2012, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> > On 11/01/2012 6:28 p.m., kimi ge(����) wrote:
> >> Hi,
> >>
> >> I have an issue to make squid 3.1.x to work with IIS SharePoint as
> the
> >> back-end.
> >> The details are listed below.
> >>
> >> 1. squid 3.1.x is running as a reverse-proxy.
> >> 2. The back-end is IIS SharePoint Site with domain authentication
> >> required.
> >> That means only the valid domain user could access this SharePoint
> site.
> >> The issue is it always return 404 error page. And the logon window is
> >> not prompted.
> >
> > What is this "domain authentication" you mention? All of the HTTP auth
> > mechanisms count as "domain auth" to a reverse proxy, and none of them
> > are named "Domain".
> >
> >>
> >> My question is whether squid supports this kind of case or not?
> >> If supports, how should I do configuration on squid.conf file?
> >>
> >> Thanks in advance.
> >> ~Kimi
> >
> > 404 status is about the resource being requested _not existing_. Login
> > only operates when there is something to be authorized fetching. So I
> > think auth is not relevant at this point in your testing.
> >
> > Probably the URL being passed to IIS is not what you are expecting to be
> > passed and IIS is not setup to handle it. You will need to share your
> > squid.conf details for more help.
> >
> > Amos
> >
Received on Wed Jan 11 2012 - 08:42:20 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 11 2012 - 12:00:02 MST