[squid-dev] Build failed in Jenkins: trunk-matrix » gcc,j-fbsd-93 #353

See -- [...truncated 1329 lines...] if test "off" != "" && test "off" != "no" && test "off" != "off" && test -f ../.././test-suite/../errors/en.po; then lang=`basename

Re: [squid-dev] The next step towards: StoreID and metalink.

On 22/09/2015 00:57, Amos Jeffries wrote: Using 302 kind of defeats the purpose of metalinks: that the content can be fetched from alternative URLs if one breaks in any way (by the client, or by Squid on revalidation retries). > Using StoreID helper to re-write the IDs to the same cached

[squid-dev] need help for using squid

Hi: I am a developer from Beijing of China, these Days, when using squid(version 3.5.8),I met some problems,my goal of program is making the computer(system of ubuntu 14.04) as a cache server ( only ipa and apk files can be saved),my computer has two network cards ,one is wired ,the other

Re: [squid-dev] The next step towards: StoreID and metalink.

Well I cannot say ignore now but yes I started a draft and stopped and then next time I Look at the keyboard it is in the squid list while I wanted to delete it. Eliezer On 21/09/2015 22:42, Eliezer Croitoru wrote: I would not push to add the functionality to squid\ECAP. To tell the truth

[squid-dev] Build failed in Jenkins: trunk-full-matrix » clang,j-fbsd-93 #9

See -- [...truncated 1336 lines...] if test "off" != "" && test "off" != "no" && test "off" != "off" && test -f ../.././test-suite/../errors/en.po; then lang=`basename

[squid-dev] Build failed in Jenkins: trunk-full-matrix » gcc,j-fbsd-93 #9

See -- [...truncated 1330 lines...] if test "off" != "" && test "off" != "no" && test "off" != "off" && test -f ../.././test-suite/../errors/en.po; then lang=`basename

Re: [squid-dev] The next step towards: StoreID and metalink.

On 09/21/2015 03:40 PM, Eliezer Croitoru wrote: > The first step now I am trying to grasp first what could be done in the > current state of squid and ECAP without any changes. > Currently the ECAP module can calculate hashes on the fly and then in > the end of the transaction write the result to

Re: [squid-dev] The next step towards: StoreID and metalink.

On 22/09/2015 01:46, Alex Rousskov wrote: The checksum computation and 302 redirections (vie REQMOD request satisfaction) that you have described above are as realistic as changing Squid/eCAP. I do not think realism is the deciding factor here. Alex. OK then the first steps towards something

Re: [squid-dev] [PATCH] keep track of the size of uploads done with CONNECT

On 16/09/2015 7:29 a.m., Aymeric Vincent wrote: > > Hi, > > thank you for your detailed explanations. > > Alex Rousskov writes: > >> 1a. Since you are polishing tunnelStart() profile anyway, delete the >> status_ptr parameter as well. AFAICT, that parameter

Re: [squid-dev] [PATCH] Parser-NG conversion of ICAP pt2

On 09/21/2015 08:46 AM, Amos Jeffries wrote: > On 24/08/2015 8:40 a.m., Amos Jeffries wrote: >> It turns out that ICAP implements has three distinct protocol parsers. >> >> I begin the ICAP parser conversion to the Parser-NG model with >> ModXact::parseHeaders() - which was conflating both ICAP

Re: [squid-dev] [PATCH] Do not update gperf-generated files through make

A slightly more working version. If this works, please feel free to commit. Amos === modified file 'scripts/source-maintenance.sh' --- scripts/source-maintenance.sh 2015-08-04 05:32:35 + +++ scripts/source-maintenance.sh 2015-09-21 17:11:56 + @@ -260,27 +260,30 @@ for f in

[squid-dev] [PATCH] Do not update gperf-generated files through make

Hi, since we include the gperf-generated files in the source distribution, it doesn't really make sense to build them through Make - depending on the relative timestamps of the .cci and .gperf files at checkout, some systems may decide to rebuild the .cci file. The side effect of such a rebuild

Re: [squid-dev] [PATCH] Do not update gperf-generated files through make

On 09/21/2015 10:24 AM, Kinkie wrote: >since we include the gperf-generated files in the source > distribution, it doesn't really make sense to build them through Make > - depending on the relative timestamps of the .cci and .gperf files at > checkout, some systems may decide to rebuild the

Re: [squid-dev] [PATCH] Do not update gperf-generated files through make

On 22/09/2015 4:40 a.m., Alex Rousskov wrote: > On 09/21/2015 10:24 AM, Kinkie wrote: > >>since we include the gperf-generated files in the source >> distribution, it doesn't really make sense to build them through Make >> - depending on the relative timestamps of the .cci and .gperf files at

[squid-dev] Build failed in Jenkins: trunk-matrix » clang,j-fbsd-93 #353

See -- [...truncated 1335 lines...] if test "off" != "" && test "off" != "no" && test "off" != "off" && test -f ../.././test-suite/../errors/en.po; then lang=`basename

Re: [squid-dev] The next step towards: StoreID and metalink.

On 09/21/2015 01:28 PM, Amos Jeffries wrote: > On 22/09/2015 6:19 a.m., Alex Rousskov wrote: >> On 09/19/2015 05:28 PM, Eliezer Croitoru wrote: >> >>> There are things which can help an ECAP module to decide how to do >>> things when handling metalinks related affairs. >>> For example, a cache

Re: [squid-dev] The next step towards: StoreID and metalink.

On 22/09/2015 6:19 a.m., Alex Rousskov wrote: > On 09/19/2015 05:28 PM, Eliezer Croitoru wrote: > >> There are things which can help an ECAP module to decide how to do >> things when handling metalinks related affairs. >> For example, a cache object lookup from within an ECAP module. >> So

[squid-dev] Build failed in Jenkins: trunk-matrix » gcc,j-fbsd-93 #354

See -- [...truncated 1331 lines...] if test "off" != "" && test "off" != "no" && test "off" != "off" && test -f ../.././test-suite/../errors/en.po; then lang=`basename

Re: [squid-dev] The next step towards: StoreID and metalink.

Alex, Amos, The first step now I am trying to grasp first what could be done in the current state of squid and ECAP without any changes. Currently squid provides the methods to modify a request and\or response. Basic StoreID support in a REQMOD should be possible in any case to allow an ECAP