because we lack time.
I there anything more I could do to help or should I rather just remain quiet
and patient, which I will happily do?
Please be patient :-)
None of this stuff is lost or rejected, I just havn't gotten to it yet.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
In message 15639.1274170...@critter.freebsd.dk, Poul-Henning Kamp writes:
In message 4bf24c0a.40...@schokola.de, Nils Goroll writes:
http://varnish-cache.org/changeset/4796
Once you're at it, it would appear to me that adding differentiated macros for
load/store/both (AMD64: lfence/sfence/mfence
I have updated the 2.1.3 candidate patch at
http://phk.freebsd.dk/misc/_.2.1.3.patch
Please help test it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
that be, that the author of Varnish said that it is by
far the least hackish way to get something working reliably.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
In message aanlktin6vuioe8hbweu+bhkm4g8c5uoetbkqjskkm...@mail.gmail.com, T.
Pascal writes:
Just wondering when/if req.hash can be used like the above error (or,
with the new log feature)?
req.hash is not coming back as a readable variable, it is too expensive
in storage.
--
Poul-Henning Kamp
to return graced
content on backend failure.
In order to not confuse the syntax more than necessary, we
should probably introduce return (deliver_graced) both
in vcl_miss{} and vcl_fetch{}.
Comments ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since
one char
if (c == CR)
Rx one char
if (c != LF)
accept fetch
log error notice
close connection to prevent reuse
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
In message 8762vtx0tm@qurzaw.linpro.no, Tollef Fog Heen writes:
]] Poul-Henning Kamp
| Please do.
It was already set to pkglibdir, so I just adjusted that to
pkglibdir/vmods and exposed that in the pkg-config file. I don't think
we want to promote this to a configure option, people
: Variable 'filelist_update' (line 199, file ../../lib/libvmod_std/vmod
_std.c)
+could be declared as const
+../../lib/libvmod_std/vmod_std.c 199 Info 830: Location cited in prior
+message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since
-Disposition: inline
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
--===4723512172216386742==--
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
),
((ptr)-s_hdrbytes + (ptr)-s_bodybytes ...))
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
...
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
a 304 response.
Correct.
It was good to see everybody at VUG, hope you're all doing well and
getting hit often. %^)
Yes, nothing like being able to use your hands to communicate with
also :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
and conditional_timeout SHALL also be set to zero.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message 4d662da4.3030...@uplex.de, Geoff Simmons writes:
On 2/24/11 9:59 AM, Poul-Henning Kamp wrote:
In message 4d6578ce.7070...@uplex.de, Geoff Simmons writes:
@phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl
is set to 0, wouldn't existing VCL continue to do what
policies,
where objects can linger for longer in the hope they are reused.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
60 seconds, it will be removed.
It is enough to say:
set obj.ttl = 0s;
set obj.conditional_timeout = 60s;
obj.grace (and obj.conditional_timeout) are automatically zeroed
when you zero obj.ttl
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP
In message 4d7a1b77.1090...@yahoo.co.uk, Dmitry Panov writes:
There is definitely a problem with the current trunk.
is this with or without geoffs ims-patch ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD
In message 4d7a1dc5.7030...@yahoo.co.uk, Dmitry Panov writes:
Both. The patch doesn't make any difference.
Ok, that makes it my department :-)
Any indication what the leak depends on ?
number of requests ?
size of requests ?
hit rate ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus
?
Are there any other kinds of request normalization we should do ?
And should we also normalize backend responses ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
, Poul-Henning Kamp wrote:
In message4d7a1dc5.7030...@yahoo.co.uk, Dmitry Panov writes:
Both. The patch doesn't make any difference.
Ok, that makes it my department :-)
Any indication what the leak depends on ?
number of requests ?
size of requests ?
hit rate ?
--
Dmitry Panov
not totally disable
IMS on an object.
Which is more intuitive ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message 4d7cbc4c.2070...@schokola.de, Nils Goroll writes:
All other tests fail sometimes, but not reproducibly, with an Assert error in
TCP_blocking(), tcp.c line 184: Condition(TCP_Check(j)) not true..
Keep an eye on errno...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
In message 4d7c9077.4020...@uplex.de, Geoff Simmons writes:
So I think that with max(grace,keep), and default_keep == default_grace,
we have the widest range of options and simplest defaults.
Works for me.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP
to think about this
themselves.
Obviously that is nor particularly practical either.
What I'm looking for is the sensible middle ground...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
{
cookie.keep_only(This_cookie, That_cookie);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
the slight silliness and inelegance of this, does it cause
any real-world problems?
I worry about quoting madness...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
). This because it will
always output a comma in preparation for the arguments. Attached is a patch
to correct this and only supply the comma when it is needed.
This should be fixed now. I didn't quite use your patch, because the
fix makes the 'q' variable pointless.
--
Poul-Henning Kamp | UNIX
to nail down a stable API across releases
for some of the most central bits in Varnish, and that would just
be an empty illusion.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
-dev@varnish-cache.org
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
--===8734530158992454258==--
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
In message CANTn4cpDaV6=bstz1Uv12_zSDqghj3e_qsrnKc=VhTSy=8s...@mail.gmail.com
, Martin Blix Grydeland writes:
Find attached proposed fix for #980.
Almost correct: The C-L and do_stream tests belong together.
Committed in fixed form.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev
per worker thread in wrk-nbusyobj, without
locking, which will be good for low hit-rates.
Stats counters will allow us to monitor the situation and
improve this policy.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
' was more of a joke than a serious bid, but we
simply couldn't come up with anything better at the time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
in the phrase There, but for the grace of god, go I etc.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
-dev
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev
.
It can, but the synth reply cannot be ESI parsed.
I did consider the alternative, where you call synth() from vcl_recv{}
and then go from there to vcl_fetch{}, in essense making synth{} a
virtual backend.
Would that be better ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing
values for consistency.
+ if (vary1[2] || vary2[2])
+ /* number of headers doesn't match */
+ return 0;
We should always put {...} around if-bodies, if they are more than one
line, even if the second line is a comment.
--
Poul-Henning Kamp | UNIX since Zilog
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev
In message 20120426185723.ga9...@rox.home.comstyle.com, Brad Smith writes:
Unlike the 3.0.2 release checking out the latest and greatest from Git
doesn't fare well building on OpenBSD. The following diff fixes the
build issues.
Committed, thanks.
--
Poul-Henning Kamp | UNIX since Zilog
here, but I notice that we (still!)
have no docs at all for our install-strategy.
I'm not looking for a big bulky thing, just a one-pager which says
Varnish installs these files these places for theses reasons.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP
___
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
is beeing remapped and backends will perform better.
Sorry about the delay.
I have done it slightly differently in [master] 0352ea2...
Feel free to yell at me if that is not good enough.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
, -spersistent
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
at that time.
There is certainly no need to record the bantimes in the segment
(0016), since they are already there in the ban-spec.
non-mentioned patches are not reviewed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
at that, you are more than
welcome.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
, there is a storage hint: You can pick and choose which stevedore
you want to prefer, not sure if it will do all you need in this case,
but I think it would help.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
should probably just fail the
request with 50x.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
(req.backend, req.url)) {
return (deliviver)
}
}
sub vcl_fetch {
if (beresp.status = 400) {
saint.bad(bereq.backend, bereq.url);
}
}
--
Poul-Henning Kamp | UNIX since Zilog
;
+ VSC_C_main-n_lru_nuked++;
+ }
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message 20121011035912.cc6531acb4464292dde9d...@lodoss.net, Federico G. S
chwindt writes:
I'm not sure I understand what you are trying to do here, and I wonder
if you're not doing it backwards ?
Wouldn't a
DOUBLE std.unixtime(TIME)
make more sense ?
--
Poul-Henning Kamp
In message cajv_h0alpdossrvptqorcdqxtg0nh_hcvseygio3jqb1wug...@mail.gmail.com
, Federico Schwindt writes:
On Thu, Oct 11, 2012 at 9:24 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 20121011035912.cc6531acb4464292dde9d...@lodoss.net, Federico
G. S
chwindt writes:
I'm not sure I
it gets
a proper type.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message 76841.1349946...@critter.freebsd.dk, Poul-Henning Kamp writes:
Can you try this patch ?
(NB: copypasted, you probably need to apply by hand...)
(PS: and place open a ticket for this bug)
diff --git a/lib/libvcl/vcc_expr.c b/lib/libvcl/vcc_expr.c
index 72c26a9..5223392
flag in cache_ban.c which indicates that a shutdown
is in progress, set it in the BAN_Shutdown() function.
When this flag is set, all attempts to add bans should fail before
trying to grab the mutex.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since
In message 508ebaf5.2020...@schokola.de, Nils Goroll writes:
Niels, can't we find some way to assert that we get the privs
which are supported ?
I'm sort of paranoid about silent priv-sep issues, because they have
a tendency to become security exploits...
--
Poul-Henning Kamp
think that is a good idea. Warnings tend to become it always says that...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
list. The varnish-dev list is for
varnish development topics.
With all due respect: I don't think we positively know at this point
if varnish works on ia64, so I think this could be a valid -dev issue.
(See my other reply)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
about any of the other options there)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
, it's not important for what we're trying
to do.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
AS
##---
Ok, now we're getting somewhere
Can you check that the bin/varnishd/default.vcl file does not
look like that in the first line ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
is a bit tight for me right now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
in spirit, but I think it is wrong in practice: We
want to start the pools as early as we can so they can create their
minimum complement of threads.
The right thing to do is probably to introduce and raise a flag when
when are in business.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
.vtc so it should probably be done in its own commit.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
now, but I think there
is a substantial change here which needs to be salvaged still ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
thing is the (Always!) move... rule, which
ensures that a single backend never gets to service
the full load.
Emperically, chosing A as round(min(2, log2(n_backends)))
works pretty well.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
I won't be online for the bug-wash tomorrow due to a meeting.
Apologies for the late notice.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
In message 20121126082805.gc31...@err.no, Tollef Fog Heen writes:
It hasn't really been marked as deprecated
well, we removed it from the on-line help...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
the generated VCL and run raw.
Would this work ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
don't know if it is useful for varnish core because varnish usually don't
care about requests body (POST), but it is useful for me as a VMOD developer.
Send patch :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
have not had
time to track it down.
-enable-diagnostics may possibly change the -O and -g flags to the
compiler, which could change the code generation enough to obscure
the issue.
Any kind of further information you can find, is more than welcome...
--
Poul-Henning Kamp | UNIX since Zilog
--090507030006090308070204--
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
().
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing
OK
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev
prioritization,
but under present circumstances, your input in this respect is just
one of many, I get to try to balance them all, and in this particular
case you loose: These are not security problems.
I've argued many times:
And I've said many times:
Please send patches.
--
Poul-Henning Kamp
examples of non-insane uses of headers longer
than 127 characters ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
on, but
they must still be able to run on req::thread for pass.
The operation starts in a few minutes...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
because they simple don't work for me.
However: I'm open to suggestions and consensus
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
VMOD
in the varnish releases.
I don't have much concrete feedback though, I hope others can weigh
in with that...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
possible)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev
In message 02e01ef8-1131-4357-b2cd-594434f0e...@crucially.net, Artur Bergman
writes:
If I end up in error and want to return the stale object, how would I do =
that?
Do a restart.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD
a consensus and send me a patch...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
=# - /#
or is it a database lookup to figure out the mapping ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
^Hhope that people will
restrain themselves
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish
-off
synthetic response to a single client. That object cannot and will
not be cached.
vcl_backend_synth{} on the other hand, will allow you to create objects
which _can_ be cached, although by default the will probably not be.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
of 100K is not unheard of, with inline images
and such.
Hand the devil a finger... :-)
I'll add it to the list
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
a STRING parameter as
suggested by Tollef. Not sure if this is still required.
VCL_IP is the right type.
I can't remember if VCC has code to type-convert a STRING to IP, but
if not, that should be added.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP
and EXP, but it will take
more code, since they don't traverse the list today.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
In message 5233a227.9070...@schokola.de, Nils Goroll writes:
On 09/13/13 09:43 AM, Poul-Henning Kamp wrote:
For the time being: This does not change the fact that the exp thread will
still
need to lock the objhead list, right?
In the case were somebody else nukes an object (de-dup, length
) != NULL)
+ tmp = strdup(getenv(TMPDIR));
+ else
+ tmp = strdup(/tmp);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
as I know, there is no way to wait on a socket
until all queued data has been sent (or even ACKed).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
tempted to make client.identity a STRING, rather than
an IP, to make it clear to people that running it through an ACL
is a bad idea.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
the client tells it to, but it can also be used synchronize
multiple clients or servers running in parallel.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
1 - 100 of 472 matches
Mail list logo
