[squid-users] Blank page due to 500 internal server error of embedded page
Can someone help mit to analyze why opts.optimize.webtrends.com throws a 500 error and therefor blocks the viewing of www.microsoft.com, when we try to open it through our squid 3.1.0? We only get a blank page while accessing www.microsoft.com since the webtrends page is a showstopper. It does work without the webtrends part if we use an acl to block opts.optimize.webtrends.com but the goal is to use it. In my access log I see at that point such an entry: 1406807304.655 22 10.32.15.38 TCP_MISS/500 814 GET http://ots.optimize.webtrends.com/ots/ots/js-3.2/311121/WT3kWEufwRsLlH8slwbtLTNN5QBiDzq9vp8gZr621gN75AfQRSUmjjmHw9v467a1LAsHxv8mErZFm2WnMzL7PG0U9WUAA9EVl-8Uq3AiHWJWXYnai8ClAbSlc0KTREwYxOcNuFSx056gNwrphrXOnv4lgdNE_6MNho1ocIMLKqOKzfbq3NOUNSuELXAXZLW5He6xZbq69vVOnYxGSb1_4sXYFBoDykxYI-2MiTFFZ4yLYpWHerYcZTErfZmCv-IvxLf1jnEj5NCdO38RY6TZnnhQCxmLC6T6uWCDb5C-YTjjOHBWO8_9Bk0JhetB3JQ260sbHwAMS-4ML2t765WLj9P9XWgHCvVueZR94AfUJcvFTquX5mvCcsqmLmdTXiMWH_QPAiKoelxQsDs9dha9-2uhbNkqIp_XL_warU0y6dhrLJK0gETba7dYGpGxxgDVEgxy_NdVVeuiS1F1qUHo0cWEX9Wpgg9IMSwPIfKrXHsqr6tfwnh4eS2uqBUmmUKTIy2iagb_iLeKwSDDUQ2uexOBTnyGZIuTdZnOV70vARXeG5m32bRxb6mbWhXI9GLLI_DTq-PED-e7C55zw77Ej59Yenj4EvAH3MCtuxZgF-aP00hpAAIYY2-Sm_Xii6XJvrmnVvVvBxNaMUtrepN5KfFAOOIcjCvKT24PfAb-kY2GiVzjydcb1dr3vl0Z2KOrn9Ffw3kVobQNeCUn4vmvs6yd8DGmmyBcvuEa2zgLcHRsuG72V62i8nIA_zX5LPrPRTk_wMo5LY0FwrLri-u80pJ3F0PZW-fqUPuh3Q9rro1EnV5w1hse2UYp2_qjYThcZ-GzynlSp5DXY2uFWaDJdQvhymrBHzKtejJGUUOW-A8AEOr3sCCNDG3k2eAUVkI9iCQAVVtU2sJWzxJb6b2gcgRdz6THeKkNYAuac! 4F3Svh6v 5tw_YxU3IJK7fjGiOov1r0xIpsDHJMLltAKHEvq2q10xamtxvUst3abc7g7DZJAdPK-Psv1HT10NWD8bpN9m__Ks7zzoFPtjK0iVbGYRgeOIG7OYV9-XoyvSvFpzx2po0WLluGzIy5MxWFCQpPX4iIJoFc4khz25Q3poV6FzM7yRpoWIpZVYo_iSrfr-dCrJ5nJXRXkrbYs_oJq3oBM8J4HXuw8SOUqfdppXxNwDPf_LOg0TLw3CFDgeY_Hn67LbInwgy0wQer67BBpg3PQfS4mouJkqO-ayWB2ybOkjrQNx6RfYIuZNIZfuc4S2lzRLxJx6WPrQCTbu3u1EDBrUef2SvSZrXI_joes5JFxRcXkiB3GHtgHjbON_KsxBq5xIz2ZIO4EEIDxpSSm7z3xxr9GMWelYX9ARtJzfkLkaqZa-J6z00sIu5z4EB0KRzjEHYXPvuw6IsEu3fuUFvaMxsE9Edli44dtwXqtzmXBW3ZpX20P_-GwgJSrdwDrYlDScrwcimKWiiCuOcwsqkUtg6F6cxNSAcpsYgXGGRA3kFmMDCqrZPHeVksw3aN6cA4lM7xi0CQbSNyfDK8liy8WFhtb-APhDSnUb0h8Yeh-J9UJV_39pQIP_DIQWZRcpb4altJZgB8dPSfg4vXpoyhMZs8bf20NJosLX3zmyDfStSQI7oV5eOUJEr2w4uDENkziWBN7loRld9HzAFwXIAHo7a-URpWfRiteWg0iNT9W6IuI7J2Z3pwtypFQuYjeR8Th7lXa-ip9-hpTCTgaaG2mLnxHk6c0NkoXyoZqFfnN8NE96Gzs1hpdYYSzha3LztWrJXfRFirLgHoHLbJ60mjeJ-FR9_IZMyNRiaxDOFAbOd1S6E9L5Tf7VuOJjFujfyxGx9y0QmYfTEHkeLyoU8bhD9WJoDZ0Uwp--1PSJmAFQHFbb1YkbMIS9jruhpSdfSe2HvrHtxy8Z6FKuv3tcZCfcM8UMxL18-! 9M1zg7kPc EexJ-omBVY4AYA3Z5isSSnRwibBpQVRMaDEXV5QRjKhUVJWcdYjhQw~~ - HIER_DIRECT/31.186.231.66 text/html What setting could cause such a behaviour or how do I find out which setting? Thank you in advance. Best regards Sebastian
[squid-users] Re: 3.HEAD and delay pools
The delay pools still not work. I don't understand why a class 1 delay pool not accept the delay_parameters 1 -1/-1 -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/3-HEAD-and-delay-pools-tp4667023p4667113.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: Announce: ETPLC projet check Treats on Squid logs.
Hi, looks interesting. Which of the 3 variants (.pl, .py2/3) do you think is the fastest one ? I am willing to trade RAM usage for speed on my embedded system. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Announce-ETPLC-projet-check-Treats-on-Squid-logs-tp4667111p4667114.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: Announce: ETPLC projet check Treats on Squid logs.
Pls, correct your log format specific:
http://etplc.org/squid.html
Actual version results in
squidFATAL: Can't parse configuration token: '%h %{Referer}h
%{Cookie}h'
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Announce-ETPLC-projet-check-Treats-on-Squid-logs-tp4667111p4667115.html
Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] RE: Centos 6.5 , Squid 3.4.3-1.el6.i386 Transparent HTTPS , SSL_BUMP , HTTPS part not working
Hello Robert, First I follow the firsts steps for replicate your scenery, for next to do the solved steps, all its ok and fixed with initial error with certificates, but after was fix it, and any errors showed, but after restart squid after all configurations (with OK at START message) , the squid status says: squid dead but pid file exists and the proxy do not filter anything, neither http or https (squid is not working) and I not know to do. Please any reason for that? what mean that?. Regards. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Centos-6-5-Squid-3-4-3-1-el6-i386-Transparent-HTTPS-SSL-BUMP-HTTPS-part-not-working-tp4665375p4667118.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Blank page due to 500 internal server error of embedded page
On 1/08/2014 9:08 p.m., Sebastian Fohler wrote: Can someone help mit to analyze why opts.optimize.webtrends.com throws a 500 error and therefor blocks the viewing of www.microsoft.com, when we try to open it through our squid 3.1.0? We only get a blank page while accessing www.microsoft.com since the webtrends page is a showstopper. It does work without the webtrends part if we use an acl to block opts.optimize.webtrends.com but the goal is to use it. In my access log I see at that point such an entry: 1406807304.655 22 10.32.15.38 TCP_MISS/500 814 GET http://ots.optimize.webtrends.com/ots/ots/js-3.2/311121/WT3kWEufwRsLlH8slwbtLTNN5QBiDzq9vp8gZr621gN75AfQRSUmjjmHw9v467a1LAsHxv8mErZFm2WnMzL7PG0U9WUAA9EVl-8Uq3AiHWJWXYnai8ClAbSlc0KTREwYxOcNuFSx056gNwrphrXOnv4lgdNE_6MNho1ocIMLKqOKzfbq3NOUNSuELXAXZLW5He6xZbq69vVOnYxGSb1_4sXYFBoDykxYI-2MiTFFZ4yLYpWHerYcZTErfZmCv-IvxLf1jnEj5NCdO38RY6TZnnhQCxmLC6T6uWCDb5C-YTjjOHBWO8_9Bk0JhetB3JQ260sbHwAMS-4ML2t765WLj9P9XWgHCvVueZR94AfUJcvFTquX5mvCcsqmLmdTXiMWH_QPAiKoelxQsDs9dha9-2uhbNkqIp_XL_warU0y6dhrLJK0gETba7dYGpGxxgDVEgxy_NdVVeuiS1F1qUHo0cWEX9Wpgg9IMSwPIfKrXHsqr6tfwnh4eS2uqBUmmUKTIy2iagb_iLeKwSDDUQ2uexOBTnyGZIuTdZnOV70vARXeG5m32bRxb6mbWhXI9GLLI_DTq-PED-e7C55zw77Ej59Yenj4EvAH3MCtuxZgF-aP00hpAAIYY2-Sm_Xii6XJvrmnVvVvBxNaMUtrepN5KfFAOOIcjCvKT24PfAb-kY2GiVzjydcb1dr3vl0Z2KOrn9Ffw3kVobQNeCUn4vmvs6yd8DGmmyBcvuEa2zgLcHRsuG72V62i8nIA_zX5LPrPRTk_wMo5LY0FwrLri-u80pJ3F0PZW-fqUPuh3Q9rro1EnV5w1hse2UYp2_qjYThcZ-GzynlSp5DXY2uFWaDJdQvhymrBHzKtejJGUUOW-A8AEOr3sCCNDG3k2eAUVkI9iCQAVVtU2sJWzxJb6b2gcgRdz6THeKkNYAuac! 4F3Svh6v 5tw_YxU3IJK7fjGiOov1r0xIpsDHJMLltAKHEvq2q10xamtxvUst3abc7g7DZJAdPK-Psv1HT10NWD8bpN9m__Ks7zzoFPtjK0iVbGYRgeOIG7OYV9-XoyvSvFpzx2po0WLluGzIy5MxWFCQpPX4iIJoFc4khz25Q3poV6FzM7yRpoWIpZVYo_iSrfr-dCrJ5nJXRXkrbYs_oJq3oBM8J4HXuw8SOUqfdppXxNwDPf_LOg0TLw3CFDgeY_Hn67LbInwgy0wQer67BBpg3PQfS4mouJkqO-ayWB2ybOkjrQNx6RfYIuZNIZfuc4S2lzRLxJx6WPrQCTbu3u1EDBrUef2SvSZrXI_joes5JFxRcXkiB3GHtgHjbON_KsxBq5xIz2ZIO4EEIDxpSSm7z3xxr9GMWelYX9ARtJzfkLkaqZa-J6z00sIu5z4EB0KRzjEHYXPvuw6IsEu3fuUFvaMxsE9Edli44dtwXqtzmXBW3ZpX20P_-GwgJSrdwDrYlDScrwcimKWiiCuOcwsqkUtg6F6cxNSAcpsYgXGGRA3kFmMDCqrZPHeVksw3aN6cA4lM7xi0CQbSNyfDK8liy8WFhtb-APhDSnUb0h8Yeh-J9UJV_39pQIP_DIQWZRcpb4altJZgB8dPSfg4vXpoyhMZs8bf20NJosLX3zmyDfStSQI7oV5eOUJEr2w4uDENkziWBN7loRld9HzAFwXIAHo7a-URpWfRiteWg0iNT9W6IuI7J2Z3pwtypFQuYjeR8Th7lXa-ip9-hpTCTgaaG2mLnxHk6c0NkoXyoZqFfnN8NE96Gzs1hpdYYSzha3LztWrJXfRFirLgHoHLbJ60mjeJ-FR9_IZMyNRiaxDOFAbOd1S6E9L5Tf7VuOJjFujfyxGx9y0QmYfTEHkeLyoU8bhD9WJoDZ0Uwp--1PSJmAFQHFbb1YkbMIS9jruhpSdfSe2HvrHtxy8Z6FKuv3tcZCfcM8UMxL18-! 9M1zg7kPc EexJ-omBVY4AYA3Z5isSSnRwibBpQVRMaDEXV5QRjKhUVJWcdYjhQw~~ - HIER_DIRECT/31.186.231.66 text/html What setting could cause such a behaviour or how do I find out which setting? * Extremely long URL 2061 bytes. Anything 1024 has low reliability. * Possibly containing several invalid characters un-encoded in the path section (CR and SP). * Unidentified issue on the upstream server. Note that 31.186.231.66 has been sent the request, the 500 status is either generated by that server or by Squid breaking on something in its reply output. First step is to try upgrading your Squid. 3.1.0 is not an official version, 3.1.0.X releases are betas. The current stable release is 3.4.6. You can also do far better debugging of HTTP with debug_options 11,2 in the current releases. Possible workaround is to add this near the top of your access rules: acl WT dstdomain ots.optimize.webtrends.com http_access deny WT Amos
