f both pending merges to 2.7 and 2.HEAD specific features.
>
> So at the moment it looks like there will be one final Squid-2.7 release
> collecting some pending bug fixes, after which maintenance of the
> Squid-2 tree will cease completely, enabling the project to focus
> entirely on Squid-3.
>
> Regards
> Henrik
>
--
Mark Nottingham m...@yahoo-inc.com
list, starting at:
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0024.html
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
<http://bugs.squid-cache.org/show_bug.cgi?id=2956>
Has anyone looked into this, or even confirmed it?
It's kind of a major breakage, and I'm surprised no one else has run into it...
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
will happen, hence my question. I'm even less sure
about the use cases for request-timeout, for the reasons you mention.
Cheers,
On 10/03/2011, at 2:10 PM, Robert Collins wrote:
> On Fri, Mar 11, 2011 at 6:22 AM, Mark Nottingham wrote:
>> <http://tools.ietf.org/html/draft-thomso
particular -
1) is this interesting enough that you'd implement if it came out?
2) if someone submitted a patch for this, would you include it?
3) do you see any critical issues, esp. regarding performance impact?
Thanks,
--
Mark Nottingham m...@yahoo-inc.com
Has anyone tried squid with lessfs or ZFS in dedup mode?
Just curious; I read a paper once that implied that Traffic Server used to do
dedup internally, but apparently it doesn't any more...
--
Mark Nottingham m...@yahoo-inc.com
s
> kid1| WARNING: unparseable HTTP header field {: , 1.1 cup-www-cache01: 80}
> kid1| WARNING: unparseable HTTP header field {: , 1.1 cup-www-cache02: 80}
> kid1| ctx: exit level 0
--
Mark Nottingham m...@yahoo-inc.com
tity age calculation.
>
> Account for response delay in entity age calculation as described in RFC
> 2616 section 13.2.3.
>
> Co-Advisor test cases:
> test_case/rfc2616/ageCalc-none-7-none
> test_case/rfc2616/ageCalc-5400-4-5
>
--
Mark Nottingham m...@yahoo-inc.com
down to each request being independent; you don't want requests
affecting other ones (beyond anything, it's a security issue if you allow
clients to purge your cache indescriminantly).
--
Mark Nottingham m...@yahoo-inc.com
e
> entire message, and MAY be sent either in a response or in a
> request. If sent in a request, a cache MUST NOT store any part of
> either this request or any response to it.
>
> Thank you,
>
> Alex.
--
Mark Nottingham m...@yahoo-inc.com
Yep. I didn't hit the 'publicise' button to make that public, tho; figured I'd
leave that to you.
Cheers,
On 16/08/2010, at 12:52 PM, Henrik Nordström wrote:
> fre 2010-08-13 klockan 18:54 -0500 skrev Mark Nottingham:
>
>> P.S., if any other squid-dev people
Absolutely. The only reason I didn't do it is that I'm not as familiar with
bazaar...
Cheers,
On 16/08/2010, at 8:22 AM, Robert Collins wrote:
> Its fine by me; we could push squid3 up as well using bzr-git, if folk
> are interested.
>
> -Rob
--
Mark Nottingham m...@yahoo-inc.com
P.S., if any other squid-dev people are on github, we can add you to the group,
FWIW, although like I said, this is read-only...
--
Mark Nottingham m...@yahoo-inc.com
On 30/06/2010, at 6:46 PM, Alex Rousskov wrote:
> ICP and HTCP _servers_: share listening sockets.
Am I right that currently, it's effectively a random process that handles the
query or CLR, and no state / effects are shared among processes?
Cheers,
--
Mark Nottingham m.
FYI, I've asked Mozilla to stop sending Proxy-Connection:
https://bugzilla.mozilla.org/show_bug.cgi?id=570283
Any additional thoughts here? Should Squid stop using it, to encourage its
demise (I won't use the word "early," as it's been around far too long already)?
Ch
>> messages.
>
> caching POST messages in Squid is hard to implement due to Squid not
> buffering the POST body before forwarding the request.
>
> Regards
> Henrik
>
--
Mark Nottingham m...@yahoo-inc.com
Has anything been applied to 3 yet? I'd like to apply this patch, but don't
want conflicting / slightly different configuration or implementation.
Cheers,
On 22/05/2010, at 1:53 PM, Mark Nottingham wrote:
> Bug w/ patch for 2.HEAD at:
> http://bugs.squid-cache.org/show
no
> cachedirs ? That excludes mem-only caching (or perhaps thats not
> supported now).
>
> -Rob
--
Mark Nottingham m...@yahoo-inc.com
Any thoughts about this one?
http://bugs.squid-cache.org/show_bug.cgi?id=2957
--
Mark Nottingham m...@yahoo-inc.com
Now <http://bugs.squid-cache.org/show_bug.cgi?id=2956>.
Can anyone else reproduce this? I'm a bit surprised it hasn't bitten someone
else.
On 16/02/2010, at 5:45 PM, Mark Nottingham wrote:
> - it *does* hit VARY_REFRESH first
> - threshold for the vary problem is m
skov wrote:
> On 05/19/2010 08:00 PM, Mark Nottingham wrote:
>> Minor suggestions for the documentation:
>>
>> +NAME: access_sibling_when_stale
>> +COMMENT: on|off
>> +TYPE: onoff
>> +DEFAULT: off
>> +LOC: Config.onoff.access_sibling_for_stale_resource
&
Bug w/ patch for 2.HEAD at:
http://bugs.squid-cache.org/show_bug.cgi?id=2931
On 18/05/2010, at 4:33 PM, Henrik Nordström wrote:
> tis 2010-05-18 klockan 15:12 +1000 skrev Mark Nottingham:
>
>> /*
>> * The 'need_validation' flag is used to prevent
, siblings
+ that do not have the 'allow-miss' cache_peer option will
+ be queried even when there is a stale cached response.
+DOC_END
H, is setting the default to on a bad thing?
I'll produce the patch for 2.HEAD.
Regards,
--
Mark Nottingham m...@yahoo-inc.com
ordström wrote:
> tis 2010-05-18 klockan 22:59 +1000 skrev Mark Nottingham:
>
>> Any thoughts about moving where refreshCheck is called for HTCP?
>
> Haen't looked at it. What is the problem?
>
> Regards
> Henrik
>
--
Mark Nottingham m...@yahoo-inc.com
OK.
Any thoughts about moving where refreshCheck is called for HTCP?
Cheers,
On 18/05/2010, at 4:33 PM, Henrik Nordström wrote:
> tis 2010-05-18 klockan 15:12 +1000 skrev Mark Nottingham:
>
>> /*
>> * The 'need_validation' flag is used to prevent
the patch when it comes through. Are you
> looking at an option that can be set on cache_peer per-peer? or
> globally?
>
> FYI, Some administrative details to be aware of:
>
> There is about 2 months to go before 3.2 goes into beta. I'm hoping
> for July 1st, dependin
A bit more;
- it *does* hit VARY_REFRESH first
- threshold for the vary problem is much lower
- evident since (at least) Squid 2.7STABLE1
On 15/02/2010, at 8:59 PM, Mark Nottingham wrote:
> I'm seeing some strange behaviour when using collapsed_forwarding on large
> respons
o rely on value of maximum_object_size_in_memory
- does not appear to be specific to disk or null disk caching
- problem #2 seems to be caused by a Vary header
- does not appear to be related to VARY_RESTART; clientCacheHit: Vary MATCH!
Does this seem familiar to anyone? I'll file a bug
currently being prepared.
>
> If I have overlooked any other patches you think should have been
> included then speak up now. You have approximately 16 hours before the
> releases is frozen.
>
> Regards
> Henrik
>
--
Mark Nottingham m...@yahoo-inc.com
ly a XLS dump cross-test of the Co-Advisor
> results. Plus manual estimations for the "guess" column.
>
> I've forgotten what was on the Sheet2. So yes it's missed a few rounds of
> updates.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
> Current Beta Squid 3.1.0.15
--
Mark Nottingham m...@yahoo-inc.com
For that matter, we could get all of this into 2.7, if we relax it...
On 23/01/2010, at 11:02 AM, Amos Jeffries wrote:
> Mark Nottingham wrote:
>> Now that Adrian has moved his work to Lusca, it looks like the Squid 2.8
>> roadmap <http://wiki.squid-cache.org/RoadMap/Squid2
I'm not against that, as long as 2.8 isn't rigidly feature-locked. It would be
a bit weird, IMO, but I can live with it.
On 23/01/2010, at 11:02 AM, Amos Jeffries wrote:
> Mark Nottingham wrote:
>> Now that Adrian has moved his work to Lusca, it looks like the Squid 2.
d, although
I'm not really up to full release management. Any guidance, etc. would be
helpful.
WRT the roadmap, is the best thing to do to remove the current information and
start collecting a list of applicable bugs? Or can we just give them a
Milestone of 2.8 in bugzilla?
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
ase wherever we have a callback) is the right approach, first.
Cheers,
On 17/12/2009, at 10:24 PM, Mark Nottingham wrote:
> I've put a basic proof-of-concept into a bug; see
> <http://bugs.squid-cache.org/show_bug.cgi?id=2835>.
>
> It only logs client FDs, but give
;
Feedback / sanity checking appreciated.
On 25/02/2009, at 6:40 PM, Henrik Nordstrom wrote:
> ons 2009-02-25 klockan 12:10 +1100 skrev Mark Nottingham:
>
>> What am I missing? The most straightforward way that I can see to do
>> this is to add an identifier to clientHttpReq
On 08/12/2009, at 4:12 PM, Henrik Nordstrom wrote:
> tis 2009-12-08 klockan 13:34 +1100 skrev Mark Nottingham:
>
>> Any thoughts here? Should this really be >=, or should clientProcessBody
>> never get a 0 size_left?
>
> It's done when size_left == 0, and no
hed
'all'
2009/12/08 18:34:24| clientProcessBody: start fd=54 body_size=0 in.offset=420
cb=0x45602f req=0xdbeac0
2009/12/08 18:34:24| assertion failed: client_side.c:4445:
"conn->body.size_left > 0"
On 08/12/2009, at 5:23 PM, Mark Nottingham wrote:
> #2 0x
start = 1260237328.5134871
#8 0x0046722c in main (argc=3, argv=0x7fbfffd798) at main.c:862
errcount = 0
On 08/12/2009, at 4:12 PM, Henrik Nordstrom wrote:
> tis 2009-12-08 klockan 13:34 +1100 skrev Mark Nottingham:
>
>> Any thoughts here? Should this really be >=, or s
thoughts here? Should this really be >=, or should clientProcessBody never
get a 0 size_left?
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
AM, Henrik Nordstrom wrote:
Sorry, lost the thread a bit here over the 1.5 year that has passed.
What was this about?
fre 2009-10-30 klockan 11:26 +1100 skrev Mark Nottingham:
Since the HTCP purging is tied up in httpMaybeRemovePublic, I think
this needs to happen in storePurgeEntriesByUrl; e.g
is logic down to
httpMaybeRemovePublic, for a starter making it not remove the object
itself which is the primary case this test is for..
Regards
Henrik
--
Mark Nottingham m...@yahoo-inc.com
nt-side and server-side behaviours. I know this
is probably intentional, but people will read all sorts of things into
this header (especially since its name is so similar to other HTTP
headers) unless you give some indication of what it means.
--
Mark Nottingham m...@yahoo-inc.com
On 17/10/2009, at 9:09 AM, Ian Hickson wrote:
On Wed, 14 Oct 2009, Mark Nottingham wrote:
Section 5.2 does constrain the bytes the server accepts from the
client,
thereby conflicting with HTTP, but only in some small details. In
particular, it makes HTTP header field-names case-sensitive
scheme
-- it would avoid a lot of the fragility we've been concerned about on
the HTTP side.
Cheers,
* Ian, are you just trying to exceed 100 drafts, thereby crashing the
IETF? :)
On 14/10/2009, at 10:07 AM, Robert Collins wrote:
On Wed, 2009-10-14 at 09:59 +1100, Mark Notting
On 13/10/2009, at 10:23 PM, "Ian Hickson" wrote:
I want to just use port 80, and I want to make it possible for a
suitably
configured HTTP server to pass connections over to WebSocket
servers. It
seems to me that using something that looks like an HTTP Upgrade is
better
than just having
gards
Henrik
ons 2009-09-02 klockan 19:17 +1000 skrev Mark Nottingham:
Hm.
I'm trying 3.HEAD now, but it's giving me some trouble; analysis
starts up fine, but when it gets to doing cf_gen_defines, it switches
over to using g++ and doesn't switch back; see below.
cf_gen didn't
/Checklist.Plo
/bin/sh ../../libtool --tag=CXX --mode=link g++ -I/usr/include/
libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -
D_REENTRANT -g -O2 -g -o libapi.la Acl.lo Checklist.lo -lm -lresolv
mkdir .libs
ar cru .libs/libapi.a Acl.o Checklist.o
ranlib .libs/libapi.
it's pretty easy.
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
cbdataFree(fwdState);
internalStart(r, e);
return;
correct?
See modified patch below.
miss_access_slow.patch
Description: Binary data
Thanks again,
On 29/06/2009, at 11:12 AM, Alex Rousskov wrote:
On 06/29/2009 12:30 AM, Mark Nottingham wrote:
OK.
WRT requestlin
o you really need to print this
email?
--
Mark Nottingham m...@yahoo-inc.com
irewall/proxy to control access to the internet?
That stuff is going to need upgrading sure, but I'd rather see the
upgrade happen once to a well thought out and reasonably well designed
protocol, versus having lots of little upgrades need to occur because
your "HTTP but not quite HTTP" exchange on port 80 isn't thought out
enough.
Adrian
--
Mark Nottingham m...@yahoo-inc.com
Yep. Just think it's worth pointing out in the draft, since you go to
such efforts to make this possible.
Cheers,
On 17/07/2009, at 10:28 AM, Ian Hickson wrote:
On Fri, 17 Jul 2009, Mark Nottingham wrote:
Realise that server-side infrastructure often includes things like
CDNs
-middle proxies, this isn't a
big
deal -- the people implementing the server side are in control of
what the
HTTP implementation is doing.
--
Mark Nottingham m...@yahoo-inc.com
On 16/07/2009, at 12:28 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Mark Nottingham wrote:
As an alternative, why not:
1) specify a new port for "normal" WebSocket operation, and
2) specify that if there's a proxy configured, ask the proxy to
CONNECT to
your new port, and
WS you can specify whatever you like), it
allows "normal" HTTPS-over-443 to work, etc.
They can even do the same handshake over TLS on 443 if they like
(without the proxy).
On 15/07/2009, at 5:59 PM, Ian Hickson wrote:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Can you remind
On 15/07/2009, at 5:34 PM, Ian Hickson wrote:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Upgrade is hop-by-hop, so it's pretty limiting.
Do man-in-the-middle proxies count as a hop for the purposes of
HTTP? As
far as I can tell from the HTTP spec, the client is supposed to know
wh
d it - why exactly again aren't you just talking HTTP on
the HTTP port(s), and doing a standard HTTP upgrade?
Adrian
--
Mark Nottingham m...@yahoo-inc.com
I noticed that in section 3.1.3 the spec relies implicitly on CONNECT
being allowed to arbitrary ports. But this is not the case for
default
installs of squid, and thus I fear that the general approach may be
flawed.
--
Mark Nottingham m...@yahoo-inc.com
Upon request, Dave Dykstra provided a BSD licensed version of the
script he uses for running multiple instances of Squid listening to a
single port.
Can we get this included in contrib?
Cheers,
Begin forwarded message:
From: Dave Dykstra
Date: 7 July 2009 6:35:19 AM
To: Mark Nottingham
OK.
WRT requestlink, I was unsure what would happen if the request didn't
go forward; will moving requestLink at the bottom up to here:
fwdState->request = r; /* requestLink? */
do it?
Thanks,
On 27/06/2009, at 3:05 AM, Alex Rousskov wrote:
On 06/16/2009 09:57 PM, Mark Nottingh
Yeah, saw that --- but I observed the same behaviour in 2, and can't
figure out why (from a quick look, at least).
Cheers,
On 18/06/2009, at 2:19 PM, Amos Jeffries wrote:
On Thu, 18 Jun 2009 10:20:09 +1000, Mark Nottingham >
wrote:
Weird. The code that I'm assuming generat
uid-3, but I'm observing
the same behaviour in my build of 2...
On 17/06/2009, at 4:00 PM, Mark Nottingham wrote:
[ moving to squid-dev ]
From what I can see, the site is using JavaScript to do autocomplete
on a search field. The autocomplete requests use POST, but without a
body.
With
eone else does!
http://mail.promotions.yahoo.com/newdomains/aa/
Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/
--
Mark Nottingham m...@yahoo-inc.com
Thanks. Anybody else have a second to look?
On 11/06/2009, at 11:28 PM, Amos Jeffries wrote:
Mark Nottingham wrote:
Would someone mind taking a quick look at this patch:
http://www.squid-cache.org/bugs/attachment.cgi?id=1989
and telling me if I've royally stuffed up with managing fwd
request headers do not match
the stored request headers. Therefore, the cache must not use the
stored entry to construct a response.
--Jason
Mark Nottingham wrote:
What requirement in RFC2616 does this violate?
On 13/06/2009, at 3:02 AM, Jason Noble wrote:
I recently ran into a bug on Squid
,
Jason
--
Mark Nottingham m...@yahoo-inc.com
Would someone mind taking a quick look at this patch:
http://www.squid-cache.org/bugs/attachment.cgi?id=1989
and telling me if I've royally stuffed up with managing fwdState and
request linking?
It's to make miss_access a slow lookup...
Thanks,
--
Mark Nottingham
Can those familiar with the ins and outs of the Vary implementation
have a quick look at
http://www.squid-cache.org/bugs/show_bug.cgi?id=2678
to see if I'm on the right track?
If so, I'll come up with a patch, as well as one for 1947 (which looks
to be quite similar).
Cheers
On 2-HEAD.
On 14/05/2009, at 6:36 PM, Mark Nottingham wrote:
On 23/04/2009, at 10:38 AM, Mark Nottingham wrote:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
http://www.squid-cache.org/bugs/show_bug.cgi?id=2631
These are the last two remaining. There's been some discussi
Patch at:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2673
On 19/05/2009, at 1:50 PM, Mark Nottingham wrote:
tools.c:fatal() dumps core because it calls abort.
Considering that the core can be quite large (esp. on a 64bit
system), and that there's fatal_dump() as well if you r
dent error states.
I'll come up with a patch that does that and adds a FATAL_DUMPS
compile-time flag with a 0 default.
What do you mean by that last?
I think if you are going to correct the fatal() and fatal_dump()
usage it
won't be needed.
Amos
On 20/05/2009, at 11:28 AM, Mark Not
that and adds a FATAL_DUMPS
compile-time flag with a 0 default.
On 20/05/2009, at 11:28 AM, Mark Nottingham wrote:
The case that triggered this for me was when the log daemon dies;
doesn't make much sense to core there either.
I'll take a look through and report back.
On 20/0
That I agree with. Grep the code for all fatals and see what falls
out.
I think you will find it's only the config parser that can get away
with
non-core fatals.
Amos
On 19/05/2009, at 2:25 PM, Adrian Chadd wrote:
just make that behaviour configurable?
core_on_fatal
to fatal_dump. From
what I've seen they'll be a small minority at best...
On 19/05/2009, at 2:25 PM, Adrian Chadd wrote:
just make that behaviour configurable?
core_on_fatal {on|off}
Adrian
2009/5/19 Mark Nottingham :
tools.c:fatal() dumps core because it calls abort.
Consider
tools.c:fatal() dumps core because it calls abort.
Considering that the core can be quite large (esp. on a 64bit system),
and that there's fatal_dump() as well if you really want one, can we
just make fatal() exit(1) instead of abort()ing?
Cheers,
--
Mark Nottingham m...@
ontrol the requests using it when they really need to.
Pending any objections I'll add as registered headers in 3.0 and the
above handling for Translate in 3.1.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
Current Beta Squid 3.1.0.7
--
Mark Nottingham m...@yahoo-inc.com
On 23/04/2009, at 10:38 AM, Mark Nottingham wrote:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
http://www.squid-cache.org/bugs/show_bug.cgi?id=2631
These are the last two remaining. There's been some discussion on
them, but I believe the issues have been resolved in the
. This may be overly sensitive
however.
--
Mark Nottingham m...@yahoo-inc.com
All applied to 2-HEAD.
On 09/05/2009, at 12:43 PM, Amos Jeffries wrote:
Mark Nottingham wrote:
Just a few more;
HTCP logging
http://www.squid-cache.org/bugs/show_bug.cgi?id=2627
+1.
ignore-must-revalidate
http://www.squid-cache.org/bugs/show_bug.cgi?id=2645
+1.
Create request
-revalidate, stale-if-error
http://www.squid-cache.org/bugs/show_bug.cgi?id=2647
--
Mark Nottingham m...@yahoo-inc.com
I'm neutral on this. Chris, the what that Robert talks about is what I
had originally thought, but I'm not dead-set either way...
On 05/05/2009, at 12:25 PM, Robert Collins wrote:
On Tue, 2009-05-05 at 12:17 +1000, Mark Nottingham wrote:
The functionality? Very much so; I'v
The functionality? Very much so; I've been thinking about adding this
sort of thing for a while. Very useful if you're running an accelerator.
On 05/05/2009, at 12:12 PM, Robert Collins wrote:
On Tue, 2009-05-05 at 11:57 +1000, Mark Nottingham wrote:
Yeah, but if I had a do-over
Yeah, but if I had a do-over, I'd make it simpler. This is *much*
simpler...
On 05/05/2009, at 9:46 AM, Robert Collins wrote:
surrogate-control is an existing, defined header that should do this
cleanly, and squid-3 already supports.
-Rob
--
Mark Nottingham m...@yahoo-inc.com
On 23/04/2009, at 2:11 PM, Amos Jeffries wrote:
On 21/04/2009, at 10:44 AM, Mark Nottingham wrote:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
Amos, any thoughts about the revised patch ("monitor-direct")?
I still don't agree that this is anything close to t
On 21/04/2009, at 10:44 AM, Mark Nottingham wrote:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2642
Seems uncontroversial, applying.
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
Amos, any thoughts about the revised patch ("monitor-direct")?
http://www.squid-cach
s). This
information
is not to be used or stored by any other person and/or organisation.
--
Mark Nottingham m...@yahoo-inc.com
bably check for duplicate calls somehow
too.
But this is good for a quick fix.
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
-1 right now. see bug report.
Responded there.
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
mewhat by dropping the timeout, doing one connect when >1 IPs
found, and only trying one peer per request, using netdb to improve
the
peers chances of working, but still hitting the problem.
--
Mark Nottingham m...@yahoo-inc.com
Responses inline, and a couple more:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2642
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
On 20/04/2009, at 4:46 PM, Amos Jeffries wrote:
Mark Nottingham wrote:
Unless I hear otherwise, I'm going to apply the patches attached to
Responses inline, and a couple more:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2642
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
On 20/04/2009, at 4:46 PM, Amos Jeffries wrote:
Mark Nottingham wrote:
Unless I hear otherwise, I'm going to apply the patches attached to
Unless I hear otherwise, I'm going to apply the patches attached to
the following bugs:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2631
http://www.squid-cache.org/bugs/show_bug.cgi?id=2632
http://www.squid-cache.org/bugs/show_bug.cgi?id=2515
--
Mark Nottingham m...@yahoo-inc.com
These are all now on HEAD.
On 23/02/2009, at 3:14 PM, Mark Nottingham wrote:
I'd like to see the patches attached to the following bugs applied
to 2.HEAD;
http://www.squid-cache.org/bugs/show_bug.cgi?id=2482 (deep ctx errors)
http://www.squid-cache.org/bugs/show_bug.cgi?id=2566 (sen
-4b2e-ad30-3d9ec49ee...@mnot.net
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
Browsing through
http://www.squid-cache.org/Versions/v2/2.7/cfgman/
and the 2.6 manual, it seems like the argument types for all config
directives are missing... has something changed?
--
Mark Nottingham m...@yahoo-inc.com
I was talking about request number quotas (e.g., "you can make n
requests in m minutes").
Regarding byte quotes -- see subsequent message -- I disagree that you
need eCAP :)
On 27/02/2009, at 10:00 AM, Kinkie wrote:
On Thu, Feb 26, 2009 at 11:23 PM, Mark Nottingham inc.com>
he in-squid iCap-alike Alex has been working on?)
-Rob
--
Mark Nottingham m...@yahoo-inc.com
allowed to download 5
exe's
per day or 5 requests of >1meg or something like that (it just
popped into
my head :) )
Bytes is a pretty straight forward one, the user is only allowed x
amount of
bytes per y amount of time.
Anyways - let the ideas fly :)
Cheers,
Pieter
--
Mark Nottingham m...@yahoo-inc.com
fre 2008-11-28 klockan 10:34 +1100 skrev Mark Nottingham:
Agreed. How would you pass it into debug()? It looks like _db_print
already takes variable length args,
By adding it to the context already used by _db_print.. i.e. by
extending ctx_enter to take the sequence number in addition to url
bug.cgi?id=2567 (assertion in
method patches)
http://www.squid-cache.org/bugs/show_bug.cgi?id=2599 (idempotent start)
http://www.squid-cache.org/bugs/show_bug.cgi?id=2602 (raise MAX_URL)
Any objections to doing so?
--
Mark Nottingham m...@yahoo-inc.com
http://www.squid-cache.org/bugs/show_bug.cgi?id=2599
On 31/10/2008, at 3:59 AM, Alex Rousskov wrote:
On Thu, 2008-10-30 at 00:58 +0100, Henrik Nordstrom wrote:
On tor, 2008-10-30 at 10:03 +1100, Mark Nottingham wrote:
Hmm, good point. My aim was just start and stop. Seem reasonable to
just
1 - 100 of 242 matches
Mail list logo
