Re: [squid-users] Squid 3.1.8 is available
3.1.8出ました。 - Bug 2583: pure virtual method called 含まれています。 で、こんなこと書いてあります。 This release brings several very important bug fixes, security updates and some HTTP/1.1 improvements into 3.1. swg.dump の squid はさくっと入れ替えておきます。 --- 栃原 崇 / Takashi Tochihara Internet Initiative Japan Inc. From: Amos Jeffries Subject: [squid-users] Squid 3.1.8 is available Date: Sun, 05 Sep 2010 00:48:11 +1200 > The Squid HTTP Proxy team is very pleased to announce the > availability of the Squid-3.1.8 release! > > > This release brings several very important bug fixes, security updates > and some HTTP/1.1 improvements into 3.1. > > > On the security front we have three major additions: > > * Fixes for the request processing vulnerability tagged SQUID-2010:3. >http://www.squid-cache.org/Advisories/SQUID-2010_3.txt > > * A hardening of the DNS client against packet queueing approaches used > * to enable attacks. This completes the protection against attacks > * published by Yamaguchi late in 2009. > > * An HTTP request-line parser hardened against several categories of > * request attack. This greatly increasing the speed of detection and > * reducing resources used to detect these categories of attack. > > > Several outstanding major bugs have also been identified and fixed: > > - Bug 3020: Segmentation fault: nameservers[vc->ns].vc = NULL > - Bug 3005,2972: Locate LTDL headers correctly (again) > - Bug 2872: leaking file descriptors > - Bug 2583: pure virtual method called > > As you can see yet another attempt to get over the libtool / libltdl > build issues has been made. If you are building Squid with a libtool > 1.x version please try to do so first on these bundles without using > any of the hacks and workarounds. For any libltdl or LoadableModules > problems in this package please mention in the bug 2972 bugzilla > report along with your libtool/libltdl versions. > > > Due to the security enhancements all users of Squid-3 are urged to > upgrade to this release as soon as possible. > > > Please refer to the release notes at > http://www.squid-cache.org/Versions/v3/3.1/RELEASENOTES.html > if and when you are ready to make the switch to Squid-3.1 > > This new release can be downloaded from our HTTP or FTP servers > > http://www.squid-cache.org/Versions/v3/3.1/ > ftp://ftp.squid-cache.org/pub/squid/ > ftp://ftp.squid-cache.org/pub/archive/3.1/ > > or the mirrors. For a list of mirror sites see > > http://www.squid-cache.org/Download/http-mirrors.dyn > http://www.squid-cache.org/Download/mirrors.dyn > > If you encounter any issues with this release please file a bug > report. > http://bugs.squid-cache.org/ > > > Amos Jeffries
Re: [squid-users] Squid 3.1.8 is available
Sorry, Amos. I send the mail to wrong To: ... Just ignore my mail. --- Takashi Tochihara From: Amos Jeffries Subject: Re: [squid-users] Squid 3.1.8 is available Date: Sun, 05 Sep 2010 20:21:37 +1200 > Are you trying to question or mention something? I don't read > japanese. > > Amos > > Takashi Tochihara wrote: >> 3.1.8出ました。 >>- Bug 2583: pure virtual method called >> 含まれています。 >> で、こんなこと書いてあります。 >> This release brings several very important bug fixes, security updates >> and some HTTP/1.1 improvements into 3.1. >> swg.dump の squid はさくっと入れ替えておきます。 >> --- >> 栃原 崇 / Takashi Tochihara >> Internet Initiative Japan Inc. >> From: Amos Jeffries >> Subject: [squid-users] Squid 3.1.8 is available >> Date: Sun, 05 Sep 2010 00:48:11 +1200 >> >>> The Squid HTTP Proxy team is very pleased to announce the >>> availability of the Squid-3.1.8 release! >>> >>> >>> This release brings several very important bug fixes, security updates >>> and some HTTP/1.1 improvements into 3.1. >>> >>> >>> On the security front we have three major additions: >>> >>> * Fixes for the request processing vulnerability tagged SQUID-2010:3. >>>http://www.squid-cache.org/Advisories/SQUID-2010_3.txt >>> >>> * A hardening of the DNS client against packet queueing approaches used >>> * to enable attacks. This completes the protection against attacks >>> * published by Yamaguchi late in 2009. >>> >>> * An HTTP request-line parser hardened against several categories of >>> * request attack. This greatly increasing the speed of detection and >>> * reducing resources used to detect these categories of attack. >>> >>> >>> Several outstanding major bugs have also been identified and fixed: >>> >>> - Bug 3020: Segmentation fault: nameservers[vc->ns].vc = NULL >>> - Bug 3005,2972: Locate LTDL headers correctly (again) >>> - Bug 2872: leaking file descriptors >>> - Bug 2583: pure virtual method called >>> >>> As you can see yet another attempt to get over the libtool / libltdl >>> build issues has been made. If you are building Squid with a libtool >>> 1.x version please try to do so first on these bundles without using >>> any of the hacks and workarounds. For any libltdl or LoadableModules >>> problems in this package please mention in the bug 2972 bugzilla >>> report along with your libtool/libltdl versions. >>> >>> >>> Due to the security enhancements all users of Squid-3 are urged to >>> upgrade to this release as soon as possible. >>> >>> >>> Please refer to the release notes at >>> http://www.squid-cache.org/Versions/v3/3.1/RELEASENOTES.html >>> if and when you are ready to make the switch to Squid-3.1 >>> >>> This new release can be downloaded from our HTTP or FTP servers >>> >>> http://www.squid-cache.org/Versions/v3/3.1/ >>> ftp://ftp.squid-cache.org/pub/squid/ >>> ftp://ftp.squid-cache.org/pub/archive/3.1/ >>> >>> or the mirrors. For a list of mirror sites see >>> >>> http://www.squid-cache.org/Download/http-mirrors.dyn >>> http://www.squid-cache.org/Download/mirrors.dyn >>> >>> If you encounter any issues with this release please file a bug >>> report. >>> http://bugs.squid-cache.org/ >>> >>> >>> Amos Jeffries > > > -- > Please be using > Current Stable Squid 2.7.STABLE9 or 3.1.8 > Beta testers wanted for 3.2.0.2
Re: [squid-users] About squid ICAP implementation
From: Henrik Nordstrom <[EMAIL PROTECTED]> Subject: Re: [squid-users] About squid ICAP implementation Date: Fri, 14 Nov 2008 12:11:19 +0100 > > > Allow: 204 is sent if it's known the whole message can be buffered > > > within the buffer limits (SQUID_TCP_SO_RCVBUF). It's not relaed to > > > previews. > > > > Why is there such a limitation (SQUID_TCP_SO_RCVBUF) ? > > I hope that squid always send "Allow: 204" to icap servers as much > > as possible... > > Because to send "Allow: 204" Squid must buffer the whole message. This > buffering is done in memory. Imagine what would happen if the message is > a dual layer DVD ISO image.. (6-8GB in size). I think to send "Allow: 204" & Preview: , squid must buffer not the whole message, but the whole *Previewed* message. (part of the message) tcp (or server) keeps the message, I think. e.g. squid doest not read the message (from socket), tcp keeps the message until his buffer becomes full, and when tcp buffer is full, tcp sends window size = 0 packet and then the server keeps the message... I think it is better to send Allow: 204 header, when squid sends Preview: header. (of course Preview: values needs some limitation) Do I have the wrong idea? best regrads -- Takashi Tochihara
Re: [squid-users] About squid ICAP implementation
Hi, Henrik From: Henrik Nordstrom <[EMAIL PROTECTED]> Subject: Re: [squid-users] About squid ICAP implementation Date: Tue, 18 Nov 2008 09:34:51 +0100 > On lör, 2008-11-15 at 05:51 +0900, Takashi Tochihara wrote: > > > I think to send "Allow: 204" & Preview: , squid must buffer not the > > whole message, but the whole *Previewed* message. (part of the message) > > "Allow: 204" is not related to previews. It tells the ICAP server that > it's OK to respond with 204 at any time, even outside of the preview. > > The preview is signalled by the "Preview: " header, and implicitly > requests the ICAP server to respond with 204 or 100 at the end of the > preview to continue the transaction or possibly a syntesised response > replacing the original message. You are right. In case of the client sends Preview & Allow: 204, the servier first responds "100 Continue" and next (as a result) responds "204 No Content", squid must buffer the whole message. I understand what you said. Thank you! best regards, -- Takashi Tochihara
