[squid-users] flickr.com redirect error

[Ozgur Batur]

I receive too many redirects(301 responses with same page URL) error
on browser when opening https://www.flickr.com via Squid 3.5 proxy
with SSL interception. If I connect to flickr website directly without
Squid error does not happen.


I tested it on two different systems one is Centos other is Ubuntu.
There is no acl, redirect or any other configuration in squid.conf
except enabling SSL interception.


I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537 for this
issue but later thought it is better to ask if you also experience the
same issue.



Ozgur
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Yuri]

Try to do something like:


# 301 loop
acl text_mime rep_mime_type text/html text/plain

acl http301 http_status 301

store_miss deny text_mime http301
send_hit deny text_mime http301


24.06.2016 18:14, Ozgur Batur пишет:
I receive too many redirects(301 responses with same page URL) error 
on browser when opening https://www.flickr.com via Squid 3.5 proxy 
with SSL interception. If I connect to flickr website directly without 
Squid error does not happen.
I tested it on two different systems one is Centos other is Ubuntu. 
There is no acl, redirect or any other configuration in squid.conf 
except enabling SSL interception.
I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537 for this 
issue but later thought it is better to ask if you also experience the 
same issue.



Ozgur


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] ecap adaper

[joe]

hi wen using ecap adapter
ecap_enable on
acl HTTP_STATUS_OK http_status 200
loadable_modules /usr/local/lib/ecap_adapter_gzip.so
ecap_service gzip_service respmod_precache ecap://www.vigos.com/ecap_gzip
bypass=off
adaptation_access gzip_service allow HTTP_STATUS_OK 
wen the link has status 200   and its  POST not GET
the adapeter or ecap or squid some how wen a link has POST and the adapeter
change it to GET or its refusing POST i dont know exactly wats happening 
but the app in phone freez waiting
is there a way to bypass POST not to go trough ecap or anythink i can do

this is the link that freez has post other then that its working fine

1466763366.861   1059 10.4.4.61 TCP_MISS/200 30516 POST
http://prod2.dominationsgame.com/snc/api2?app_version=4101&hash=1&userid=6897921&st=/PU=&bh=28&sd=636023599967637129&hs=7497&rm=683627205y683627355&bmj=683627355&bmi=683627200
- ORIGINAL_DST/54.225.199.115 application/json 
[Content-Type: application/x-www-form-urlencoded\r\n
Accept-Encoding: gzip, identity\r\n
Connection: Keep-Alive, TE\r\n
TE: identity\r\n
User-Agent: BestHTTP\r\nContent-Length: 720\r\n
Host: prod2.dominationsgame.com\r\n] 

[HTTP/1.1 200 OK\r\n
Server: Apache-Coyote/1.1\r\n
Pragma: no-cache\r\n
Expires: Thu, 01 Jan 1970 00:00:00 GMT\r\n
Cache-Control: no-cache\r\n
Cache-Control: no-store\r\n
Set-Cookie: JSESSIONID=EF31B93DC2F43C30BEF805EA91CE2B92; Path=/snc/;
HttpOnly\r\n
Content-Type: application/json;charset=UTF-8\r\n
Content-Length: 30112\r\n
Date: Fri, 24 Jun 2016 10:13:18 GMT\r\n\r]




--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/ecap-adaper-tp4678171.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Ozgur Batur]

Hi Yuri,

Thank you. I put the #301 loop directives and restarted squid unfortunately
result is the same. Here is the access logs:

1466777191.791235 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
HIER_DIRECT/188.125.93.100 text/html
1466777192.031237 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
HIER_DIRECT/188.125.93.100 text/html
1466777192.386352 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
HIER_DIRECT/188.125.93.100 text/html
1466777192.612223 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
HIER_DIRECT/188.125.93.100 text/html
...

As I understand all responses are from origin server, there is no cache hit
with or without store_miss and send_hit. Confusing part is when directly
connected to server without proxy, flickr server does not send 301
response. When squid sends the same request somehow flickr server returns
301 with same URL.

Ozgur


On Fri, Jun 24, 2016 at 3:50 PM, Yuri  wrote:

> Try to do something like:
>
>
> # 301 loop
> acl text_mime rep_mime_type text/html text/plain
>
> acl http301 http_status 301
>
> store_miss deny text_mime http301
> send_hit deny text_mime http301
>
>
> 24.06.2016 18:14, Ozgur Batur пишет:
>
> I receive too many redirects(301 responses with same page URL) error on 
> browser when opening https://www.flickr.com via Squid 3.5 proxy with SSL 
> interception. If I connect to flickr website directly without Squid error 
> does not happen.
>
>
> I tested it on two different systems one is Centos other is Ubuntu. There is 
> no acl, redirect or any other configuration in squid.conf except enabling SSL 
> interception.
>
>
> I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537 for this issue but 
> later thought it is better to ask if you also experience the same issue.
>
>
>
> Ozgur
>
>
> ___
> squid-users mailing 
> listsquid-users@lists.squid-cache.orghttp://lists.squid-cache.org/listinfo/squid-users
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Hm. My opinion is the same - this is redirection loop. Just need to
localize it.


24.06.2016 20:23, Ozgur Batur пишет:
> Hi Yuri,
>
> Thank you. I put the #301 loop directives and restarted squid
unfortunately result is the same. Here is the access logs:
>
> 1466777191.791235 ::1 TCP_MISS/301 987 GET https://www.flickr.com/
- HIER_DIRECT/188.125.93.100  text/html
> 1466777192.031237 ::1 TCP_MISS/301 987 GET https://www.flickr.com/
- HIER_DIRECT/188.125.93.100  text/html
> 1466777192.386352 ::1 TCP_MISS/301 987 GET https://www.flickr.com/
- HIER_DIRECT/188.125.93.100  text/html
> 1466777192.612223 ::1 TCP_MISS/301 987 GET https://www.flickr.com/
- HIER_DIRECT/188.125.93.100  text/html
> ...
>
> As I understand all responses are from origin server, there is no
cache hit with or without store_miss and send_hit. Confusing part is
when directly connected to server without proxy, flickr server does not
send 301 response. When squid sends the same request somehow flickr
server returns 301 with same URL.
>
> Ozgur
>
>
> On Fri, Jun 24, 2016 at 3:50 PM, Yuri mailto:yvoi...@gmail.com>> wrote:
>
> Try to do something like:
>
>
> # 301 loop
> acl text_mime rep_mime_type text/html text/plain
>
> acl http301 http_status 301
>
> store_miss deny text_mime http301
> send_hit deny text_mime http301
>
>
> 24.06.2016 18:14, Ozgur Batur пишет:
>> I receive too many redirects(301 responses with same page URL)
error on browser when opening https://www.flickr.com via Squid 3.5 proxy
with SSL interception. If I connect to flickr website directly without
Squid error does not happen.
>>
>> I tested it on two different systems one is Centos other is
Ubuntu. There is no acl, redirect or any other configuration in
squid.conf except enabling SSL interception.
>>
>> I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537 for
this issue but later thought it is better to ask if you also experience
the same issue.
>>
>>
>> Ozgur
>>
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org

>> http://lists.squid-cache.org/listinfo/squid-users
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org

> http://lists.squid-cache.org/listinfo/squid-users
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXbUaJAAoJENNXIZxhPexGGpwIAK4mYSAoZbIU96VbS3L/Xq+f
6taPqkZrvy9JPU3aS92qE0bSuJFjtQrJ9lz8W8zAygeljyhCgwct9/9qBCy1gX25
7Z6qJj4UTfS7dIxb5NnAq2CHovuKiqvv6HThBqQ9J8/bq3jYk7u3rNK60ZEMK2Wg
sHaVLDiJMVu9gFCiYWlaPnBpFvse20gqybwhrhysjdM94HWAGOT9Oe+YWxIdB+Fj
lq1Udt3i4EvHrz4tOOgf5gggUVTBk7VttcKhgko9hI+KnfL3S2Yk2phzWX4apVt4
aDV/LKzb8vU33jOR9fV/sIOS0TyeBcIm3lokDWNfjB1SEjxQxXNPI1iOVggQv0Q=
=Sr78
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Rafael Akchurin]

Hello Ozgur, Yuri,

I also see this error. Actually it is even present on videos.yahoo.com if I am 
not mistaken.
The reason for this is unclear for me (incorrect handling of “Via” header by 
some of back office servers of Yahoo???)

I was able to fix it by setting “via off” in squid.conf. I am not sure if this 
is the recommended way ( I presume not) and how to disable Via only for yahoo 
servers. Hopefully Amos has better answers.

Via looks like:

Via:"http/1.1 fts110.flickr.bf1.yahoo.com (ApacheTrafficServer [cMs f ]), 
http/1.1 r02.ycpi.ams.yahoo.net (ApacheTrafficServer [cMsSf ]), 1.1 qlproxy 
(squid/3.3.8)"

Best regards,
Rafael Akchurin
Diladele B.V.

From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Ozgur Batur
Sent: Friday, June 24, 2016 4:23 PM
To: Yuri 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] flickr.com redirect error

Hi Yuri,

Thank you. I put the #301 loop directives and restarted squid unfortunately 
result is the same. Here is the access logs:

1466777191.791235 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ - 
HIER_DIRECT/188.125.93.100 text/html
1466777192.031237 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ - 
HIER_DIRECT/188.125.93.100 text/html
1466777192.386352 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ - 
HIER_DIRECT/188.125.93.100 text/html
1466777192.612223 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ - 
HIER_DIRECT/188.125.93.100 text/html
...

As I understand all responses are from origin server, there is no cache hit 
with or without store_miss and send_hit. Confusing part is when directly 
connected to server without proxy, flickr server does not send 301 response. 
When squid sends the same request somehow flickr server returns 301 with same 
URL.

Ozgur


On Fri, Jun 24, 2016 at 3:50 PM, Yuri 
mailto:yvoi...@gmail.com>> wrote:

Try to do something like:



# 301 loop
acl text_mime rep_mime_type text/html text/plain

acl http301 http_status 301

store_miss deny text_mime http301
send_hit deny text_mime http301

24.06.2016 18:14, Ozgur Batur пишет:

I receive too many redirects(301 responses with same page URL) error on browser 
when opening https://www.flickr.com via Squid 3.5 proxy with SSL interception. 
If I connect to flickr website directly without Squid error does not happen.



I tested it on two different systems one is Centos other is Ubuntu. There is no 
acl, redirect or any other configuration in squid.conf except enabling SSL 
interception.



I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537 for this issue but 
later thought it is better to ask if you also experience the same issue.


Ozgur


___

squid-users mailing list

squid-users@lists.squid-cache.org

http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Ozgur Batur]

Hi Rafael, Yuri,

Thank you very much, "via off" did the trick. It is probably a server
specific issue as you said.

Best Regards,

On Fri, Jun 24, 2016 at 6:29 PM, Rafael Akchurin <
rafael.akchu...@diladele.com> wrote:

> Hello Ozgur, Yuri,
>
>
>
> I also see this error. Actually it is even present on videos.yahoo.com if
> I am not mistaken.
>
> The reason for this is unclear for me (incorrect handling of “Via” header
> by some of back office servers of Yahoo???)
>
>
>
> I was able to fix it by setting “via off” in squid.conf. I am not sure if
> this is the recommended way ( I presume not) and how to disable Via only
> for yahoo servers. Hopefully Amos has better answers.
>
>
>
> Via looks like:
>
>
>
> Via:"http/1.1 fts110.flickr.bf1.yahoo.com (ApacheTrafficServer [cMs f ]),
> http/1.1 r02.ycpi.ams.yahoo.net (ApacheTrafficServer [cMsSf ]), 1.1
> qlproxy (squid/3.3.8)"
>
>
>
> Best regards,
>
> Rafael Akchurin
>
> Diladele B.V.
>
>
>
> *From:* squid-users [mailto:squid-users-boun...@lists.squid-cache.org] *On
> Behalf Of *Ozgur Batur
> *Sent:* Friday, June 24, 2016 4:23 PM
> *To:* Yuri 
> *Cc:* squid-users@lists.squid-cache.org
> *Subject:* Re: [squid-users] flickr.com redirect error
>
>
>
> Hi Yuri,
>
>
>
> Thank you. I put the #301 loop directives and restarted squid
> unfortunately result is the same. Here is the access logs:
>
>
>
> 1466777191.791235 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
> HIER_DIRECT/188.125.93.100 text/html
>
> 1466777192.031237 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
> HIER_DIRECT/188.125.93.100 text/html
>
> 1466777192.386352 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
> HIER_DIRECT/188.125.93.100 text/html
>
> 1466777192.612223 ::1 TCP_MISS/301 987 GET https://www.flickr.com/ -
> HIER_DIRECT/188.125.93.100 text/html
>
> ...
>
>
>
> As I understand all responses are from origin server, there is no cache
> hit with or without store_miss and send_hit. Confusing part is when
> directly connected to server without proxy, flickr server does not send 301
> response. When squid sends the same request somehow flickr server returns
> 301 with same URL.
>
>
>
> Ozgur
>
>
>
>
>
> On Fri, Jun 24, 2016 at 3:50 PM, Yuri  wrote:
>
> Try to do something like:
>
>
>
> # 301 loop
> acl text_mime rep_mime_type text/html text/plain
>
> acl http301 http_status 301
>
> store_miss deny text_mime http301
> send_hit deny text_mime http301
>
>
>
> 24.06.2016 18:14, Ozgur Batur пишет:
>
> I receive too many redirects(301 responses with same page URL) error on 
> browser when opening https://www.flickr.com via Squid 3.5 proxy with SSL 
> interception. If I connect to flickr website directly without Squid error 
> does not happen.
>
>
>
> I tested it on two different systems one is Centos other is Ubuntu. There is 
> no acl, redirect or any other configuration in squid.conf except enabling SSL 
> interception.
>
>
>
> I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537 for this issue but 
> later thought it is better to ask if you also experience the same issue.
>
>
>
>
>
> Ozgur
>
>
>
> ___
>
> squid-users mailing list
>
> squid-users@lists.squid-cache.org
>
> http://lists.squid-cache.org/listinfo/squid-users
>
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
>



-- 
H Özgür Batur
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Be careful, guys. Via is reauired to HTTP by RFC.


24.06.2016 21:40, Ozgur Batur пишет:
> Hi Rafael, Yuri,
>
> Thank you very much, "via off" did the trick. It is probably a server
specific issue as you said.
>
> Best Regards,
>
> On Fri, Jun 24, 2016 at 6:29 PM, Rafael Akchurin
mailto:rafael.akchu...@diladele.com>> wrote:
>
> Hello Ozgur, Yuri,
>
> 
>
> I also see this error. Actually it is even present on
videos.yahoo.com  if I am not mistaken.
>
> The reason for this is unclear for me (incorrect handling of “Via”
header by some of back office servers of Yahoo???)
>
> 
>
> I was able to fix it by setting “via off” in squid.conf. I am not
sure if this is the recommended way ( I presume not) and how to disable
Via only for yahoo servers. Hopefully Amos has better answers.
>
> 
>
> Via looks like:
>
> 
>
> Via:"http/1.1 fts110.flickr.bf1.yahoo.com
 (ApacheTrafficServer [cMs f ]),
http/1.1 r02.ycpi.ams.yahoo.net 
(ApacheTrafficServer [cMsSf ]), 1.1 qlproxy (squid/3.3.8)"
>
> 
>
> Best regards,
>
> Rafael Akchurin
>
> Diladele B.V.
>
> 
>
> *From:*squid-users
[mailto:squid-users-boun...@lists.squid-cache.org
] *On Behalf Of *Ozgur
Batur
> *Sent:* Friday, June 24, 2016 4:23 PM
> *To:* Yuri mailto:yvoi...@gmail.com>>
> *Cc:* squid-users@lists.squid-cache.org

> *Subject:* Re: [squid-users] flickr.com 
redirect error
>
> 
>
> Hi Yuri,
>
> 
>
> Thank you. I put the #301 loop directives and restarted squid
unfortunately result is the same. Here is the access logs:
>
> 
>
> 1466777191.791235 ::1 TCP_MISS/301 987 GET
https://www.flickr.com/ - HIER_DIRECT/188.125.93.100
 text/html
>
> 1466777192.031237 ::1 TCP_MISS/301 987 GET
https://www.flickr.com/ - HIER_DIRECT/188.125.93.100
 text/html
>
> 1466777192.386352 ::1 TCP_MISS/301 987 GET
https://www.flickr.com/ - HIER_DIRECT/188.125.93.100
 text/html
>
> 1466777192.612223 ::1 TCP_MISS/301 987 GET
https://www.flickr.com/ - HIER_DIRECT/188.125.93.100
 text/html
>
> ...
>
> 
>
> As I understand all responses are from origin server, there is no
cache hit with or without store_miss and send_hit. Confusing part is
when directly connected to server without proxy, flickr server does not
send 301 response. When squid sends the same request somehow flickr
server returns 301 with same URL.
>
> 
>
> Ozgur
>
> 
>
> 
>
> On Fri, Jun 24, 2016 at 3:50 PM, Yuri mailto:yvoi...@gmail.com>> wrote:
>
> Try to do something like:
>
> 
>
> # 301 loop
> acl text_mime rep_mime_type text/html text/plain
>
> acl http301 http_status 301
>
> store_miss deny text_mime http301
> send_hit deny text_mime http301
>
> 
>
> 24.06.2016 18:14, Ozgur Batur пишет:
>
> I receive too many redirects(301 responses with same page
URL) error on browser when opening https://www.flickr.com via Squid 3.5
proxy with SSL interception. If I connect to flickr website directly
without Squid error does not happen.
>
> 
>
> I tested it on two different systems one is Centos other
is Ubuntu. There is no acl, redirect or any other configuration in
squid.conf except enabling SSL interception.
>
> 
>
> I opened http://bugs.squid-cache.org/show_bug.cgi?id=4537
for this issue but later thought it is better to ask if you also
experience the same issue.
>
> 
>
> 
>
> Ozgur
>
> 
>
> ___
>
> squid-users mailing list
>
> squid-users@lists.squid-cache.org

>
> http://lists.squid-cache.org/listinfo/squid-users
>
> 
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org

> http://lists.squid-cache.org/listinfo/squid-users
>
> 
>
>
>
>
> --
> H Özgür Batur

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXbVmoAAoJENNXIZxhPexGPFgH/ib6RKjQ/JhhnvTtBQnM6euV
+F6e/rrf6B295OpsrUgqFdogmCshJZGivdSBd8266KPOlvxE3I0F01SNBtAt96wC
1pL3Sam+TmFwbOGa5vYStQ+ZAkn5ReiSHppKVdeR1lXxBlMuhcDJovIxDtXvVV5G
SZcmJWT1q+LS8vcS+mGybXOt0H7J32sSUyor+qJ0CZEfG5HEPb1XKjave1mJNxUj
JEwsL0/B5zVw8LtL2yOzZY7E3ERY0r2ieGqQ4GpzYUVoDwoc5q8xwKaU08j5qyrP
iS2fW8wbAZ2RoZmvJRxnFpFKel0NgzwrAOUeSAs8hPONUUpWaklFTL55lezNY+A=
=t07f
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys

[squid-users] Squid question with letsencrypt

[Bidwell, Christopher]

Hi all,

I'm very new to squid and we are wanting to implement letsencrypt for our
ssl certificates.

Here's the scenario:

We've got several frontend servers running squid that are caching from the
backend systems.

i.e. test.com -> 10.0.0.1, 10.0.1.1, 10.0.2.1 (all physically separated
from one another)

Each internal server also has its own dns name:

web1.test.com -> 10.0.0.1
web2.test.com -> 10.0.1.1
web3.test.com -> 10.0.2.1

Note that these are all public. Using 10. as examples.

I'd like to create a SAN certificate naming the 3 internal systems in
addition to the public name:

test.com, web1.test.com, web2.test.com, and web3.test.com.

On the letsencrypt forum they said that I could do a HTTP 301 redirect from
the squid servers to the backend letsencrypt server where any match for:
 /.well-known/acme-challenge/* would redirect with an HTTP 301 to that
backend letsencrypt server.  I'm not sure how to do this and the squid
documentation is not easy to comprehend.

Let me know if this isn't clear how I've explained this.


Thanks!
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ecap adaper

[joe]

if i do with regex it work it bypass it
acl redirecturls url_regex -i \/snc\/api2
adaptation_access gzip_service allow HTTP_STATUS_OK !redirecturls

this preventing method dose not work
acl nomethod method POST
adaptation_access gzip_service allow HTTP_STATUS_OK !nomethod 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/ecap-adaper-tp4678171p4678178.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid Rewrites

[Bidwell, Christopher]

Hi all,

Just curious if you could help me figure out what the equivalent of this
apache rule would be for squid:

RewriteRule  ^/dyfi/?$ http://servername.com/data/dyfi/
 [R=301,L]
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Conditional IPv6 usage

[Amos Jeffries]

On 25/06/2016 6:27 a.m., Stefan Hölzle wrote:
> Hello,
> 
> I'm having trouble configuring a forward proxy.
> My goal is the following:
> Only for one destination domain IPv6 should be used, otherwise IPv4.

This is not how the Internet Protocol (IP) works. If a domain is
advertising IPv6 addresses, then it can and should be contacted using
those addresses.

> 
> The proxy has multiple incoming IPs and multiple outgoing IPs, here is
> the relevant part of the squid.conf:
> 
> acl port80 localport 80
> acl port88 localport 88
> acl port443 localport 443
> 
> http_port 10.0.0.54:80
> http_port 10.0.0.54:443
> http_port 10.0.0.59:80
> http_port 10.0.0.59:443
> http_port 10.0.0.59:88

Problem #1: you are configuring a forward proxy on port 80 and 443 which
are registered ports for reverse-proxy traffic syntax.

This is not necessarily a big problem. But other software in the
environment that handles port 80 and 443 traffic may interpret the
format wrongly and scew things up.


> 
> acl ipA localip 10.0.0.54
> acl ipB localip 10.0.0.59
> 
> # only somedomain.asdf via IPv6
> acl domain_acl dstdom_regex -i \.somedomain\.asdf
> 
> tcp_outgoing_address 10.0.0.93 ipB port88
> tcp_outgoing_address 2001:cdba::3257:9652 ipB port88 domain_acl
> 
> tcp_outgoing_address 10.0.0.54 ipA port80
> tcp_outgoing_address 10.0.0.63 ipA port443
> tcp_outgoing_address 10.0.0.59 ipB port80
> tcp_outgoing_address 10.0.0.93 ipB port443
> 
> dns_v4_first on
> 
> Expected behavior:
> A connection on http_port 10.0.0.59:88 is requesting a domain matching
> regex "\.somedomain\.asdf", then the first matching tcp_outgoing_address
> is used, namely
> 
> tcp_outgoing_address 2001:cdba::3257:9652 ipB port88 domain_acl
> 

Expectation is a bit wrong.

tcp_outgoing_address configures _which address to use the type of
traffic that server requires. The connection has already been allowed by
tha http_access rules - which do not distinguish whether IPv4 or IPv6 is
used to contact any particular server.


You literally cannot send traffic to an IPv6 addressed server using IPv4
packet format. Nor vice versa. Squid knows that and does not attempt to
use the wrong family of IP for any outgoing traffic.

So:
- The server destination *has already been selected for use* by
determining in various *_access lists that the client is allowed to
contact that *domain*.

- IPv6 entries are ignored for IPv4 server destinations.

- IPv4 entries are ignored for IPv6 server destinations.

> 
> Actual behavior:
> A connection on http_port 10.0.0.59:88 is requesting a domain matching
> regex "\.somedomain\.net" and
> 

Incoming port has nothing to do with outgoing IP format.

* DNS tells Squid a set of IP addresses that the domain can be contacted at.

** "dns_v4_first on" tells Squid to use the servers A address(es) as
first choice before attempting IPv6 contact.

That domain *does* have an A address. So...

> tcp_outgoing_address 10.0.1.54 ipA port80
> 
> is used.

If that fails it might fail over to another IPv4 or to the domains IPv6
address.


> If I change dns_v4_first from on to off,
> 

** then "dns_v4_first on" tells Squid to use the servers  address as
first choice before attempting IPv6 contact.

** That domain *does* have an  address. So ...

> tcp_outgoing_address 2001:cdba::3257:9652 ipB port88 domain_acl
> 

... or the machines default IPv6 addresss is used when contacting the
servers  address(es).

If that fails then Squid might failover to another of the servers IPv6
addresses, or to its IPv4 address.




You can choose a particular IP from amongst the appropriate v4/v6 types
available. But you cannot force a particular type to be used.
 (though you might configure an IPv4/IPv6 address which will force
breakage on the connection).


It is the network firewalls job to determine whether *Squid* is allowed
contact from IP A to IP B. If it blocks unwanted IPv6 traffic properly,
then the normal ICMPv6 packet that comes back from the firewall will
tell Squid to try the next IP on the list for the server being contacted.


HTH
Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Rewrites

[Amos Jeffries]

On 25/06/2016 6:39 a.m., Bidwell, Christopher wrote:
> Hi all,
> 
> Just curious if you could help me figure out what the equivalent of this
> apache rule would be for squid:
> 
> RewriteRule  ^/dyfi/?$ http://servername.com/data/dyfi/
>  [R=301,L]
> 

Below, with the comments describing the meaning in context...

 # the regex pattern to match on a URL-path
 acl dyfi urlpath_regex ^/dyfi/?$

 # these matches are not allowed to continue as-is
 http_access deny dyfi

 # when a dyfi match causes a deny, redirect to this URL as 301
 deny_info 301:http://servername.com/data/dyfi/ dyfi


Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Amos Jeffries]

On 25/06/2016 3:40 a.m., Ozgur Batur wrote:
> Hi Rafael, Yuri,
> 
> Thank you very much, "via off" did the trick. It is probably a server
> specific issue as you said.
> 

Hmm. What was the Via header emitted by your proxy?

There are some common misconfigurations that can lead to a broken Via
being sent and various resulting strange behaviour.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Amos Jeffries]

On 25/06/2016 4:02 a.m., Yuri Voinov wrote:
> 
> Be careful, guys. Via is reauired to HTTP by RFC.
> 

As of RFC 7230 et al, it is officially now optional. Yay!

As of Squid-3.2 emitting HTTP/1.1, its use in preventing 1.1<->1.0
translation errors is greatly reduced. Yay!

It is still important to avoid forwarding loops though. So interceptors
and complex hierarchy installations are advised to enable it where
possible. Just for safety though, not RFC compliance.

[somewhere down on my to-do list is making Squid be a bit more flexible
that on vs off for that header].

Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] flickr.com redirect error

[Rafael Akchurin]

Hello Amos,

The Via from mine is:

Via:"http/1.1 fts110.flickr.bf1.yahoo.com (ApacheTrafficServer [cMs f ]), 
http/1.1 r02.ycpi.ams.yahoo.net (ApacheTrafficServer [cMsSf ]), 1.1 qlproxy 
(squid/3.3.8)"

Might it be the error when constructing via contents in squid? As it starts 
with 1.1 while other constructed by Yahoo all start with http/1.1 ?

Best regards,
Rafael

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Amos Jeffries
Sent: Saturday, June 25, 2016 8:05 AM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] flickr.com redirect error

On 25/06/2016 3:40 a.m., Ozgur Batur wrote:
> Hi Rafael, Yuri,
> 
> Thank you very much, "via off" did the trick. It is probably a server 
> specific issue as you said.
> 

Hmm. What was the Via header emitted by your proxy?

There are some common misconfigurations that can lead to a broken Via being 
sent and various resulting strange behaviour.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ecap adaper

[Amos Jeffries]

On 25/06/2016 12:31 a.m., joe wrote:
> hi wen using ecap adapter
> ecap_enable on
> acl HTTP_STATUS_OK http_status 200
> loadable_modules /usr/local/lib/ecap_adapter_gzip.so
> ecap_service gzip_service respmod_precache ecap://www.vigos.com/ecap_gzip
> bypass=off
> adaptation_access gzip_service allow HTTP_STATUS_OK 
> wen the link has status 200   and its  POST not GET
> the adapeter or ecap or squid some how wen a link has POST and the adapeter
> change it to GET or its refusing POST i dont know exactly wats happening 

Please add "debug_options 11,2" to your squid.conf and see what happens
in the HTTP traffic. The log snippet below is only a third of the story.

the method you posted in yoru followup:
> 
> this preventing method dose not work
> acl nomethod method POST
> adaptation_access gzip_service allow HTTP_STATUS_OK !nomethod 
> 

Is supposed to be what you do. If thats not working there is possibly a
bug somewhere. Just have to find it.


Also, what Squid version are you using? (in the squid -v output)

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid question with letsencrypt

[Amos Jeffries]

On 25/06/2016 4:48 a.m., Bidwell, Christopher wrote:
> Hi all,
> 
> I'm very new to squid and we are wanting to implement letsencrypt for our
> ssl certificates.
> 
> Here's the scenario:
> 
> We've got several frontend servers running squid that are caching from the
> backend systems.

Ok,

> 
> i.e. test.com -> 10.0.0.1, 10.0.1.1, 10.0.2.1 (all physically separated
> from one another)
> 

Ok,

> Each internal server also has its own dns name:
> 
> web1.test.com -> 10.0.0.1
> web2.test.com -> 10.0.1.1
> web3.test.com -> 10.0.2.1
> 
> Note that these are all public. Using 10. as examples.

Ok, but dangerous. That allows the frontend to be bypassed whenever a
client wants. So you will need to ensure security to the backend stays
in sync with the frontend. If you don't have to, its best to avoid that
trouble and filter everything consistently through the frontend.

That also allows the backends to avoid public CAs like LetsEncrypt
entirely. You can use a single custom CA exclusively for the
frontend<->backend traffic and have much better security settings on
those internal links since you no longer have to worry about random
visitors capabilities.

> 
> I'd like to create a SAN certificate naming the 3 internal systems in
> addition to the public name:
> 
> test.com, web1.test.com, web2.test.com, and web3.test.com.
> 
> On the letsencrypt forum they said that I could do a HTTP 301 redirect from
> the squid servers to the backend letsencrypt server where any match for:
>  /.well-known/acme-challenge/* would redirect with an HTTP 301 to that
> backend letsencrypt server.  I'm not sure how to do this and the squid
> documentation is not easy to comprehend.
> 
> Let me know if this isn't clear how I've explained this.
> 

If LetsEncrypt are contacting web1 for example. They should be going to
the backend directly. Since http://web1.test.* is not a frontend request.

Whatever server is performing the LetsEncrypt for the frontend needs to
know its doing it for the generic domain as well as itself. Squid is not
a web server, so you need to nominate a backend to do that (could be a
new one just of LetsEncrypt stuff).

For example doing it on web1 would mean fitting these lines into your
existing config (this order, but not necesarily together like this):

 acl acme urlpath_regex ^/.well-known/acme-challenge
 cache_peer_access web1 allow acme
 cache_peer_access web2 deny acme
 cache_peer_access web3 deny acme

No "redirect" involved. Just tell Squid that server is where those URL
are handled.


Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users