Re: Policy for reverting changes

fre 2012-08-17 klockan 16:03 -0600 skrev Alex Rousskov: > The above policy places places a 24 hour wait time that may not be > appropriate in emergencies. On the other hand, it may be interpreted as > a permission to revert any change that a person considers "broken" after > 7 days of squid-dev di

Re: bzr unmerge

fre 2012-08-17 klockan 19:59 +0200 skrev Kinkie: > Have you considered "bzr uncommit"? uncommit do not cut it. uncommit simply moves the branch head to a given revision discarding any later revisions, same as git reset --hard for those familiar with git. It's ok to use on a private branch to clea

Re: Policy for reverting changes

tor 2012-08-16 klockan 23:11 -0600 skrev Alex Rousskov: > I am not annoyed at the failures -- we all commit broken code once in a > while, and there is currently no good way to prevent even simple build > failures. Yes.. > I am somewhat annoyed that some failures result in commit reversal (with

Re: [RFC] squid-3.2 - SPONSORS update

sent a bit prematurely. Clarification regarding version indications added. lör 2012-07-28 klockan 14:07 +0200 skrev Henrik Nordström: > > For simplicity I'm adding @Squid-X.Y labels at the boundaries for the bzr > > copy, not sure whether to keep them in the final packag

Re: [RFC] squid-3.2 - SPONSORS update

lör 2012-07-28 klockan 18:40 +1200 skrev Amos Jeffries: > *** We have 15 days to get this updated correctly. > > The SPONSORS file is supposed to: > > * list Sponsors who paid for significant developments in the squid code, > donated hardware for devleopment etc. > > * exclude cash donation

Re: Caching responses with "Vary" responses

tis 2012-07-24 klockan 11:05 +1200 skrev Amos Jeffries: > For the Vary meta its only a few hundred bytes normally as Alexander > noted (~230 in his test). > > However some brilliant sites decide to use Cookie or User-Agent as one > of the vary components. This can bloat the entry up to a worst-

Re: Squid development environment

ons 2012-07-18 klockan 16:46 -0300 skrev Alejandro Riedel: > I'm developing under Ubuntu 12.04. I've set up Eclipse & created a > project using the 3.1 source code. Is that a good approach? Sounds good. Personally I still use vim as editor, but that's because it's what I am used to. Eclipse help

Re: Re: Caching responses with "Vary" responses

tor 2012-07-12 klockan 14:32 +0400 skrev Alexander Komyagin: > 2) What are those 235 bytes that are written to the 'vary' storeEntry > (created in setPublicKey)? And what is the purpose of that additional > storeEntry? It's the Vary header of the response so future lookups know how to build the s

Re: [RFC] cbdata NG

lör 2012-07-07 klockan 18:54 -0600 skrev Alex Rousskov: > > CBDATA_CLASS is an interface change in cbdata using delete instead of > > cbdataFree(). It's not valid to use cbdataFree() in a CBDATA_CLASS > > class. > > Correct. We have invalid cbdata uses. So those needs fixing. > The question is,

Re: [RFC] Happy Eyeballs Algorithm

lör 2012-07-07 klockan 16:33 +0300 skrev Eliezer Croitoru: > tool for their network and based on that manipulate DNS requests. > it's also a bad idea to mess up the dns queries but.. Not only a bad idea, it's a very very bad idea. And DNSSEC will promptly stop any such tampering. Ant DNS GEOIP in

Re: [RFC] cbdata NG

lör 2012-07-07 klockan 10:24 -0600 skrev Alex Rousskov: > Confirmed. cbdataReferenceDone() and friends will not call destructors > before deallocating memory for the unlocked and invalid object, as > suspected. The destructor is already called by delete. The only thing that remains is to actually

Re: [RFC] cbdataFree does not call destructor

lör 2012-07-07 klockan 09:25 -0600 skrev Alex Rousskov: > > The cbdata interface do not fit entirely to new/delete. The difference > > is that cbdataFree only marks objects as "to be freed". There may still > > be reference counts keeping it alive. > > That is what "delete foo" does as well if fo

Re: [RFC] Happy Eyeballs Algorithm

lör 2012-07-07 klockan 21:26 +1200 skrev Amos Jeffries: > What I'm thinking when reading this is that we could implement something > like this easily using the FwdState destinations array and a timeout. > While it is true that our destinations array is N-protocol rather than > 2-protocol, the sa

Re: [RFC] cbdataFree does not call destructor

lör 2012-07-07 klockan 00:04 -0600 skrev Alex Rousskov: > Squid calls cbdataFree() for objects that have non-POD data members > such as refcounted pointers. Since cbdataFree() does not call the object > destructor when freeing object memory, those data members are not > properly destroyed, lea

Re: Generic helper I/O format

tor 2012-07-05 klockan 16:00 +1200 skrev Amos Jeffries: > The blob only exists in this discussion for two reasons; the old helpers > backward compatibility requires it, and you wanted to discuss a "body" > field for the responses. Even not understanding properly the specifics > of why you want

Re: Generic helper I/O format

ons 2012-07-04 klockan 13:02 -0600 skrev Alex Rousskov: > No, it is not. BS is required if the body is present and BS is not a > valid key name. Thus, BS cannot be confused with a start of a key-value > pair _and_ if a body starts with BS as well, there is no problem because > we already know to e

Re: /bzr/squid3/trunk/ r12194: Small optimization in CommOpener statistic accounting.

tis 2012-07-03 klockan 07:52 +0200 skrev Kinkie: > > ++(conn_->getPeer()->stats.conn_open); > > > > > > IMHO we should consistently use bracketing as above to clarify in situations > > like this where there is any complex location syntax. > > It is the latter, but I had the some doubt so I doub

Re: some help about acls(not connected directly to squid )

lör 2012-06-30 klockan 00:46 +0300 skrev Eliezer Croitoru: > while reading on squid-users i understood that dstdomain acl is faster > then regex but i dont really know how they defer from each other on the > implementation. dstdomain is sortable which allows for efficient lookup algorithms to b

Re: [PATCH] add DNT (Do Not Track) header

ons 2012-06-27 klockan 10:45 +0200 skrev Alexander Holler: > > Agreed. With the change to support arbitrary headers in > > request_header_access this patch is not needed. We could also forget > > many other less common headers. > > It is, at least if people are using whitelists for headers which

Re: [PATCH] add DNT (Do Not Track) header

tis 2012-06-26 klockan 08:56 -0600 skrev Alex Rousskov: > Squid will forward any extension header by default so this patch is not > needed to support DNT forwarding. Agreed. With the change to support arbitrary headers in request_header_access this patch is not needed. We could also forget many o

Re: [PATCH] fix up external acl type dumping

tor 2012-06-14 klockan 10:23 -0600 skrev Alex Rousskov: > > +#define DUMP_EXT_ACL_TYPE_FMT(a, fmt, ...) \ > > +case _external_acl_format::EXT_ACL_##a: \ > > +storeAppendPrintf(sentry, fmt, ##__VA_ARGS__); \ > > +break > > I do not see Squid using __VA_A

Re: Avoid duplicate peers for no-direct and maybe-direct forwarding

ons 2012-05-09 klockan 10:14 -0600 skrev Alex Rousskov: > FWIW, the "duplicate peer addresses" problem does not exist in Squid 2.7 > which indirectly supports my assumption that this is a bug rather than a > feature. Squid-2 peerAddFwdServer skips duplicate peers. while (*FS) { if ((

Re: [RFC] Handle ACLs that are neither denied nor allowed

ons 2012-05-09 klockan 10:47 +1200 skrev Amos Jeffries: > IMHO; it is time to really start work towards dropping that negation > behaviour for 3.3. Moving instead to a safe default policy for each > access control list and if the end of the list is reached (or an absent > list) that policy be en

Re: Squid 3.2.0.17 on OpenBSD 5.1 100% CPU

tis 2012-05-08 klockan 15:07 +0200 skrev Henri Wahl: > Hi, > to fix some IPv6 issues I upgrades squid to 3.2.0.17 and solved the > issues but got a way slower internet connection because squid now takes > 100% CPU where it before oscillated between 50% an 70%. Is there > nything known why it raises

Re: [RFC] Handle ACLs that are neither denied nor allowed

tis 2012-05-08 klockan 13:36 -0600 skrev Alex Rousskov: > There are caveats to using custom ACL keywords (mostly revolving around > the implicit "negate the last keyword" rule), but this is the wrong > thread to discuss them. Yes. There should be a "default action" parameter to the access list ty

Re: [RFC] Handle ACLs that are neither denied nor allowed

tis 2012-05-08 klockan 12:41 -0600 skrev Alex Rousskov: > This thread started with a suggestion to add "reason" information to > the allow_t enum type so that ACL check answers can be split into > primary yes/no/other return code and supplementary code-specific > information. There is a number

Re: adding content to the cache

tis 2012-05-08 klockan 10:33 +1200 skrev Amos Jeffries: > Further to this. The HTTP specs do make PUT request bodies cacheable > under the URL the request specifies. Squid just does not support that > edge case of HTTP/1.1 yet. It would be nice to get it implemented for > the next Squid series

Re: Using squid as an SSL/TLS endpoint/unwrapper for other protocols

tis 2012-05-08 klockan 10:48 +0500 skrev Ahmed Talha Khan: > I am interested in knowing how i can use squid as an SSL endpoint for > protocols other then HTTPS. Short answer, no. Squid is an HTTP proxy. > The scenario is that i want to use its SSL > handling capability and use it for some other

Re: keepaliveNextRequest: abandoning FD

tis 2012-05-01 klockan 08:09 -0500 skrev Guy Helmer: > I'm working with code I obtained from Alex that was sync'ed with trunk as of > -r12082 (2012-03-07 v3.2.0.16+) and on a very busy system doing forward HTTP > and HTTPS proxy (but not sslBump), I am seeing lots of these messages: > > 2012/05/

Re: [RFC] 511 on auth for intercepted traffic

tis 2012-05-01 klockan 10:39 +1200 skrev Amos Jeffries: > Given that the extension status code 511 is now an official code > (http://www.rfc-editor.org/rfc/rfc6585.txt), how do we all feel about > causing it to be emitted whenever an intercepted request is configured > to require proxy_auth sati

Re: Returning HTTP/1.0 206 responses

fre 2012-04-27 klockan 13:50 -0700 skrev Andrew Scherkus: > As far as Chromium is concerned we use ETag headers as a strong > validator to determine when we should cache content and when to > invalidate and re-fetch content should the ETag change. Since ETag and > ranges aren't technically part o

Re: Returning HTTP/1.0 206 responses

tor 2012-04-26 klockan 18:39 +0200 skrev Henrik Nordström: > ons 2012-04-25 klockan 18:12 -0700 skrev Andrew Scherkus: > > > I tested out the http11 option on squid/2.7 and caching worked as > > expected in both Chromium and Firefox. I suppose my questions are: > > 1

Re: Returning HTTP/1.0 206 responses

ons 2012-04-25 klockan 18:12 -0700 skrev Andrew Scherkus: > I tested out the http11 option on squid/2.7 and caching worked as > expected in both Chromium and Firefox. I suppose my questions are: > 1) Should squid really be returning HTTP/1.0 on 206 responses when > 206 was defined as part of HTT

Re: processing of ICAP Transfer-Ignore options

mån 2012-04-16 klockan 12:34 -0300 skrev Marcus Kool: > However, looking at the RFC where the example uses "asp, bat, exe, com, ole" > it seems that the authors of the RFC were thinking of a URL-based "suffix", > not content-type. To me it indicates the set of people who worked on this part of th

Re: processing of ICAP Transfer-Ignore options

mån 2012-04-16 klockan 09:40 -0300 skrev Marcus Kool: > The idea itself is good. The problem is that it is very different > than what the ICAP RFC states. Is it? A list of file extensions that ... It says "file extensions". What is a "file"? In my mind the closest to "file" is what you

Re: processing of ICAP Transfer-Ignore options

sön 2012-04-15 klockan 22:07 -0300 skrev Marcus Kool: > Are you saying that you want to use the Content-Type header as the > main guide for determining the "file extension" ? Yes, when there is a usable content-type. > I think that any change should stay close to the vague definitions > of the I

Re: processing of ICAP Transfer-Ignore options

lör 2012-04-14 klockan 19:11 -0600 skrev Alex Rousskov: > Sure, I am just trying to find a way to improve compatibility of ICAP > agents, even though the ICAP protocol itself is using wrong concepts > when defining what was meant as a pretty useful feature. I'd propose the following algorithm: 1

Re: processing of ICAP Transfer-Ignore options

fre 2012-04-13 klockan 13:21 -0600 skrev Alex Rousskov: > Yes, but primarily because the "extension" is not clearly defined. This > is something we can address in ICAP Errata, I guess: Provide a > definition of what should be considered a "file extension", with a > disclaimer that not all agents w

Re: processing of ICAP Transfer-Ignore options

fre 2012-04-13 klockan 11:44 -0300 skrev Marcus Kool: > There is no formal definition in the RFC of what a "file extension" > is. So the question is: is the file extension of > http://zzz.com/1409303.mp4?p1=2012-xxx > "mp4" ? The use of file extension is a major bug in the ICAP protocol imho. >

Re: Query regarding HTTP Request

tis 2012-04-10 klockan 13:33 +0530 skrev Vinayak Samak: > Thanks Alex for quick replay. > Definitely I would like to work on this part. > Please provide me starting point for the same. > Whenever I will get time I will work on this and will be in touch with > squid-dev team for problems/queries.

Re: Server Name Indication for transparent https proxy

mån 2012-04-02 klockan 21:14 +0200 skrev Santiago Garcia Mantinan: > The thing I'd like to do and I haven't seen how to do with current squid, is > to allow transparent proxy of incoming https connections based on this > Server Name Indication. Maybe I missed this and it is already implemented, >

Re: [squid-users] squid + sslbump compile errors

mån 2012-04-02 klockan 16:47 +0930 skrev Michael Hendrie: > On 06/02/2012, at 10:08 AM, Henrik Nordström wrote: > > > sön 2012-02-05 klockan 14:09 -0600 skrev James R. Leu: > > > >> certificate_db.cc: In member function ‘void Ssl::CertificateDb::load()’: > >

Re: Multiple outgoing addresses for squid?

tor 2012-03-29 klockan 14:49 -0400 skrev Chris Ross: > Last time I looked, that could only accept one address. I want to bind to > multiple outgoing addresses, so I can control routing of queries. It's ACL driven. > Can tcp_outgoing_address take multiple addresses now? Does it just > rou

Re: Squid 3.2 performance question

fre 2012-03-23 klockan 19:49 +0400 skrev Alexander Komyagin: > It seems I finally figured out where the problem is. Squid 3.2.0.16 > performs host verification for each request. And this verification > produces the call to libc getaddrinfo() function (converting IP address > from text to numeric i

Re: Squid 3.2 performance question

fre 2012-03-23 klockan 19:49 +0400 skrev Alexander Komyagin: > It seems I finally figured out where the problem is. Squid 3.2.0.16 > performs host verification for each request. And this verification > produces the call to libc getaddrinfo() function (converting IP address > from text to numeric i

Re: Squid 3.2 performance question

ons 2012-03-21 klockan 12:32 +1300 skrev Amos Jeffries: > The UDS packets comes to mind, but that is a different PF_* family > type. I stopped looking at that point. > > It could be the packet MARK lookups which are done through > libnetfilter-*. I have very little idea how that library works

Re: Squid 3.2 performance question

tis 2012-03-20 klockan 16:14 +0400 skrev Alexander Komyagin: > Yep, looks like I have them in SYN_SENT for 5 secs and then they are > discarded (timeout for httperf is set for 5 secs). And what is seen on the server side? There is mainly two limits that may get hit with such results, not countin

Re: Squid 3.2 performance question

tis 2012-03-20 klockan 13:09 +0400 skrev Alexander Komyagin: > Sorry for disinformation, BIND requests are present in both RSBAC logs. > IOCTL's were removed by adding --disable-eui to Squid configuration > command, but that did not give any performance increase. ok > On Tue, 2012-03-20 at 12:37

Re: POST procedure (squid 2.7 stable9)

anks for your suggestion > on illustrating ideas. > > 在 2012年3月19日 上午11:27，Henrik Nordström > 写道： > Please describe your goal in terms of HTTP methods and > results, not > abstract "twitter like". It will be very hard to h

Re: filtering HTTPS/CONNECT (summary and continuation of discussion)

mån 2012-03-19 klockan 11:35 -0300 skrev Marcus Kool: > An unfiltered CONNECT (default for Squid) allows (SSH) tunnels. Squid standard configuration only allows port 443, which restricts this to those who intentioanlly want to pierce any network usage policy. > I foresee a change. I foresee an in

Re: POST procedure (squid 2.7 stable9)

e pressure on web servers since we distribute > the requests on many proxy servers. The content that saved on squid > can be packed and then sent to the web server later. > I hope I made point clear. > > 在 2012年3月18日 下午9:59，Henrik Nordström > 写道： > sön 2012-03

Re: POST procedure (squid 2.7 stable9)

am not entirely sure what you want to do with stored POST data. What is it from an HTTP layer point of view that you want to accomplish? Please describe your goal in terms of HTTP requests and their responses. Regards Henrik > > > Thank you( and your time) > >

Re: filtering HTTPS/CONNECT (summary and continuation of discussion)

lör 2012-03-17 klockan 11:10 -0600 skrev Alex Rousskov: > No, it will not by default. One would have to maintain a white list of > destinations that should not be bumped. Which you can't for thinks like Skype as they connect pretty much anywhere (peer-to-peer network). Regards Henrik

Re: POST procedure (squid 2.7 stable9)

tor 2012-03-15 klockan 18:40 -0700 skrev Schulz: > Simply speaking, when dealing with the POST request, squid mainly use > the readRequest-->tryParseHttp-->parseHttpReq(in which using the > urlParse to find the method ) That's the general request parsing path, parsing the request into Request

Re: [squid-users] Compiling squid 3.2.0.16 under Solaris 10

tor 2012-03-15 klockan 22:49 +0100 skrev Henrik Nordström: > tor 2012-03-15 klockan 22:18 +0100 skrev Jose-Marcio Martins da Cruz: > > > +#if !defined(AF_LOCAL) > > +#define AF_LOCAL AF_UNIX > > +#endif > > AF_UNIX is the official name. Why are we using AF_LOCAL?

Re: [squid-users] Compiling squid 3.2.0.16 under Solaris 10

tor 2012-03-15 klockan 22:18 +0100 skrev Jose-Marcio Martins da Cruz: > +#if !defined(AF_LOCAL) > +#define AF_LOCAL AF_UNIX > +#endif AF_UNIX is the official name. Why are we using AF_LOCAL? > It seems that it doesn't know the function strsep, which doesn't exists under > solaris. strsep is a

Re: filtering HTTPS

ons 2012-03-14 klockan 09:35 -0300 skrev Marcus Kool: > > non-HTTP traffic do not fit URLs or ICAP either. How would you map an > > SSH session? > > Sorry, I know virtually nothing about the internals of Squid so how > to map it... I don't know. I am talking at the protocol level, ignoring Squid

Re: filtering HTTPS

ons 2012-03-14 klockan 16:13 +1300 skrev Amos Jeffries: > We are asking an HTTP peer to Upgrade its hop. We have not sent > acceptance to the client, and will relay the peers reject/accept. No > violation there. We just loose control of a HTTP connection by trying is > all. You can only do thi

Re: filtering HTTPS

ons 2012-03-14 klockan 14:18 +1300 skrev Amos Jeffries: > huh? it says exactly what protocol the tunnel is intended to contain > (switch to). On GET/OPTIONS yes, but only for the transport, not tunnel. You can use Upgrade on CONNECT as well if you want. But it's for the client<->proxy only and

Re: filtering HTTPS

ons 2012-03-14 klockan 12:33 +1300 skrev Amos Jeffries: > Another option is to notice any Upgrade: headers in the CONNECT > requests. That is a major hint about what the tunnel contains. What? Upgrade is not related to CONNECT. It says absolutely nothing of what the tunnel contains. CONNECT is

Re: filtering HTTPS

tis 2012-03-13 klockan 19:27 -0300 skrev Marcus Kool: > > Squid is not the tool for filtering non-http(s) traffic beyond requested > > hostname. > > I agree. Squid is not. This task is for the URL rewritors and ICAP servers. > One way or another, Squid should offer all data that passes through it

Re: filtering HTTPS

tis 2012-03-13 klockan 12:12 -0300 skrev Marcus Kool: > Where does the filtering gets involved? Also NoneSSL sites (aka tunnelmode) > need to be filtered/blocked and/or scanned for virusses. Squid is not the tool for filtering non-http(s) traffic beyond requested hostname. But it would be trivi

Re: filtering HTTPS

tis 2012-03-13 klockan 12:12 -0300 skrev Marcus Kool: > > A sslbump whitelist is probably desired as well, skipping ssl/tls > > verification if it's already known the server is an https server. > > A whitelist has a security issue It's not a "bypass" list. An sslbump whitelist in this context m

Re: filtering HTTPS

And if both sides is monitored for traffic then detection do not need to rely on timeout. If any message is seen from server or if something that do not look like ssl hello is seen from client then enter tunnel mode. There is one but still, non-http protocols over ssl/tls, not just CONNECT but

Re: filtering HTTPS

There is one option more. On CONNECT first (after host based filters) verify that connection works, but nothing more. Then wait for client hello ssl packet, if no hello packet is seen within a not too long timeout or if some non-ssl/tls traffic is seen enter tunnel mode. If a ssl hello packet

Re: [squid-users] Roadmap Squid 3.2

ons 2012-03-07 klockan 10:35 -0700 skrev Alex Rousskov: > I think it is neither reasonable nor practical to make Squid v3.2 > "stable" designation dependent on 2.x bugs, especially those filed years > ago with insufficient information. Squid v3.2 can be stable regardless > of what bugs the old 2.x

Re: Uploading Mechanism in Squid

mån 2012-03-05 klockan 04:52 -0800 skrev Schulz: > I'm trying to realize the client uploading on the squid > which means users are able to use squid to save their uploading information > for example tweets. So when facing high income of client uploading request, > companies can use the squid to all

[MERGE] Correct DNS timeout handling.

This fixes up the DNS timeout management. # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: hen...@henriknordstrom.net-20120304222458-\ # 19a08w1tobnxdhy0 # target_branch: http://bzr.squid-cache.org/bzr/squid3/trunk/ # testament_sha1: 12df0be1bcabe9d4ae82e03f1d6e58035baac06c # timest

RE: range request cache

fre 2012-03-02 klockan 10:00 -0500 skrev Zhu, Shan: > Very good suggestions. If the ambiguity can be solved, I should go > ahead and give a try. Merging two ranges look genuine but it will > change the cache store and requires extra work. Say, if we have > multiple ranges which cross each other, we

Re: range request cache

lör 2012-03-03 klockan 04:23 +1300 skrev Amos Jeffries: > On 3/03/2012 4:00 a.m., Zhu, Shan wrote: > > Very good suggestions. If the ambiguity can be solved, I should go ahead > > and give a try. Merging two ranges look genuine but it will change the > > cache store and requires extra work. Say,

RE: range request cache

tor 2012-03-01 klockan 18:09 -0500 skrev Zhu, Shan: > Thanks Alex and Amos for your quick response. > > Including the range request for cache key calculation sounds more generic > than hacking the range into the object file names. I am moving toward this > direction. However there may be an ambi

Re: [PATCH] Better helper-to-Squid buffer size management.

tis 2012-02-28 klockan 17:00 -0700 skrev Alex Rousskov: > This version of the patch is meant to address all previously raised > concerns (see the "Increase helper-to-Squid buffer size and warn on > overflows" thread): Looks fine. Please commit. Regards Henrik

Re: [MERGE] Send DNS A and AAAA queries in parallel (v2)

tis 2012-02-28 klockan 15:45 +1300 skrev Amos Jeffries: > > Squid dumps core in idnsCallback() when the slave query times out > > because q->callback is nil and the callback_data validity check is > > useless. > > > > Is this actually happening? in what query events? Ack. See it now. Patch comi

Re: [PATCH] Increase helper-to-Squid buffer size and warn on overflows

tis 2012-02-28 klockan 11:09 +1300 skrev Amos Jeffries: > I would say make it a MemBuf, but there are write-related design bugs > that need fixing there first. MemBuf is missing a "reservation" interface. Not currently designed for mapping well to raw memory access for populating the data (i.e.

Re: [PATCH] Increase helper-to-Squid buffer size and warn on overflows

mån 2012-02-27 klockan 11:41 -0700 skrev Alex Rousskov: > Squid's ssl_crtd helper may produce responses exceeding 9907 bytes > in size (and possibly much larger if multiple chained certificates need > to be returned to Squid). The old helper.cc code would fill the 8KB read > buffer completely,

Re: /bzr/squid3/trunk/ r12048: Bug 3490: Crash writing Referer/Username logs

mån 2012-02-20 klockan 11:01 -0700 skrev Alex Rousskov: > I know this and the Log::Format::SquidReferer changes fix a bug and > there is already code that disables logging if agent or referrer are > absent, but I have to note that the "log nothing" approach itself is > flawed because it leads to m

Re: [RFC] [PATCH] Proposal to kill Netscape K-A hack

ons 2012-02-08 klockan 11:40 +1300 skrev Amos Jeffries: > On 08.02.2012 07:53, Alex Rousskov wrote: > > On 02/07/2012 05:36 AM, Amos Jeffries wrote: > >> Just spotted this hack killing persistence after every Unsupported > >> Request error. > >> Original was added in Squid-2.3 prior to Oct 1999 for

Re: [RFC] byte hit ratio

ons 2012-02-08 klockan 11:52 +1300 skrev Amos Jeffries: > Okay. So if I get this you are in favour of only a text change. +1, if a suitable label can be found. or keep it as-is. The number of questions will not decrease only because we change label. The confusion is it's not because the label is

Re: [RFC] byte hit ratio

tis 2012-02-07 klockan 14:01 +1300 skrev Amos Jeffries: > We have a long history of questions and bugs mentioning negative > numbers in the byte hit ratio. > > I've always thought it was a bug we had not tracked down, but the FAQ > says it is correct. > http://wiki.squid-cache.org/SquidFaq/Inner

Re: [RFC] Squid 3.1 ports

ons 2012-02-01 klockan 09:02 -0700 skrev Alex Rousskov: > If "Send DNS A and queries in parallel" is indeed just a > performance improvement, then I agree with Kinkie that we should not > port it unless there is a very strong demand for it or Henrik is 100% > certain that code is flawless. Th

Re: [RFC] Squid 3.1 ports

ons 2012-02-01 klockan 21:10 +1300 skrev Amos Jeffries: > Opinions please. > > There are three relatively large alterations in 3.2 which I'm undecided > about whether to port to 3.1. > > r11497 Henrik - Disable OpenSSL SSL/TLS Bug #workarounds by default +1. And Trivial. One line code + squid

Re: Unsupported or EoL

mån 2011-12-12 klockan 18:38 + skrev Joshua Brown: > I am curious to know which versions of Squid are considered 'end of > life' or are no longer supported, i.e., will receive no further > security patches. Can anyone provide guidance or a link? Bascially we support one release only. I.e. one

Re: /bzr/squid3/trunk/ r11986: Bug 3268: remove "Ready to serve requests." message

lör 2012-01-28 klockan 16:13 -0700 skrev Alex Rousskov: > On 01/28/2012 01:22 AM, Henrik Nordström wrote: > > What is the rest about? Very dense commit message for such large commit. > > I think he re-committed it correctly later, redoing r11986. Ah, right he did. Rewriting his

Re: /bzr/squid3/trunk/ r11986: Bug 3268: remove "Ready to serve requests." message

What is the rest about? Very dense commit message for such large commit. fre 2012-01-27 klockan 06:26 -0700 skrev Amos Jeffries: > > revno: 11986 > fixes bug(s): http://bugs.squid-cache.org/show_bug.cgi?id=3268 > committer: Amos Jeffrie

Re: [RFC] cache architecture

tor 2012-01-26 klockan 13:32 +1300 skrev Amos Jeffries: > > We are wholly dependent on the server or client providing > cache-controls that workaround the sync issues. So long as those > controls and the purge are obeyed correctly *when received* I call it > compliant. Well, the things we talk

Re: [RFC] cache architecture

- Ursprungsmeddelande - > If they have sync problems, they may violate HTTP. I am just doing my > best trying to stay focused on the [local] cache architecture topic; I > do not want to get into discussion about distributed hierarchies. Exactly. HTTP spec is written for a consistent singl

Re: [RFC] cache architecture

ons 2012-01-25 klockan 15:03 +1300 skrev Amos Jeffries: > We also need to enumerate how many of these cases are specifically > "MUST purge" versus "MUST update". The update case is a lot more lenient > to sync issues than purges are. The case which matters here is that update actions done by a

Re: [RFC] cache architecture

ons 2012-01-25 klockan 15:03 +1300 skrev Amos Jeffries: > We also need to enumerate how many of these cases are specifically > "MUST purge" versus "MUST update". The update case is a lot more lenient > to sync issues than purges are. The case which matters here is that update actions done by a

Re: [RFC] cache architecture

tis 2012-01-24 klockan 12:21 -0700 skrev Alex Rousskov: > We had to think that way before Rock because the intransit space and > cache space were the same thing. I agree that we should not, ideally, > assume that any cache (memory and/or disk) is present at any given time. > This helps with startu

Re: [RFC] cache architecture

tis 2012-01-24 klockan 21:51 +1300 skrev Amos Jeffries: > So proposals for collapsables which are too large for cache_mem? or when > "cache_mem 0"? collapsed forwarding requires the ability of an early cache hit, that is a cache hit on an object currently being stored. This is also an useful opt

Re: [RFC] Package download pages

mån 2012-01-23 klockan 15:51 +1300 skrev Amos Jeffries: > This release details are now automated by the mk-static.sh systems. All > we need to do is update the Versions/index.dyn page when new series are > created or shifted between beta/stable/deprecated status. Excellent! Regards Henrik

Re: cvs commit: www2/content/Versions/v3/3.2 make.sh

mån 2012-01-23 klockan 08:00 +0100 skrev Henrik Nordström: > sön 2012-01-22 klockan 17:04 -0700 skrev Automatic source maintenance: > > squidadm2012/01/22 17:04:49 MST > > > > Modified files: > > content/Versions/v3/3.2 make.sh > > Log: > > R

Re: cvs commit: www2/content/Versions/v3/3.2 make.sh

sön 2012-01-22 klockan 17:04 -0700 skrev Automatic source maintenance: > squidadm2012/01/22 17:04:49 MST > > Modified files: > content/Versions/v3/3.2 make.sh > Log: > Remove snapshot maintenance from make.sh. Done in index.dyn now Doesn't that require changes to v3/3.2/index.dyn a

Re: [RFC] Package download pages

mån 2012-01-23 klockan 11:42 +1300 skrev Amos Jeffries: > The current website layout for Versions/ and Download/ is a little > confusing and I would like to combine the two into a simpler form. > > The main problem is the download links and section called Download/ is > just documentation about

Re: Build failed in Jenkins: 3.HEAD-amd64-CentOS-5.3 #1781

Any idea what caused this failure? Seems like cf_gen_defines.cci was not properly built for some outside reason. sön 2012-01-22 klockan 06:12 +0100 skrev n...@squid-cache.org: > See > > Changes: > > [Henrik Nordstrom] Disa

Re: Fixing trunk build on OpenBSD

sön 2012-01-22 klockan 16:01 +1300 skrev Amos Jeffries: > On 22/01/2012 12:12 p.m., Henrik Nordström wrote: > > lör 2012-01-21 klockan 22:27 +0100 skrev Kinkie: > >> Hi all, > >>the patch below seems to fix the build on OpenBSD. Does it make sense? > > What is

SSL policy change

I just committed an SSL policy change to trunk to improve default SSL/TLS security a bit. Disable OpenSSL SSL/TLS bug workarounds by default On a closer inspection the set of "harmless" SSL/TLS bug workarounds set by SSL_OP_ALL is not all of them harmless and reduces the SSL/TLS strengt

Re: Fixing trunk build on OpenBSD

lör 2012-01-21 klockan 22:27 +0100 skrev Kinkie: > Hi all, > the patch below seems to fix the build on OpenBSD. Does it make sense? What is the error? But yes makes sense.. mgr depends on ipc I think. > Also, when nuilding by hand g++ seems to be going out-of-mem > somewhere in the test-suite

Re: [PATCH] host_verify_loose option

sön 2012-01-22 klockan 00:41 +1300 skrev Amos Jeffries: > It adds a host_verify_loose directive which allows requests which fail > Host: validation to continue through processing. The default is OFF for > now to encourage safety. Enabling this does open the clients to some > minor aspects of sa

Re: [MERGE] Send DNS A and AAAA queries in parallel (v2)

tor 2012-01-12 klockan 01:02 +1300 skrev Amos Jeffries: > +1. Please apply if you think it has had enough uasge testing. Applied. Regards Henrik

<    1   2   3   4   5   6   7   >