On Dec 5, 2011, at 2:34, Per Buer wrote:
> One forth and not related issue is "ban". We've already renamed this
> once. Most people seem to get anchored to some perception that this
> has to do with banning someone from getting content. My best
> suggestion for a new name would be "purge-filter".
Hi,
I created a new varnish module, it orders the parameters in an url
alphabetically
Code can be found here:
https://github.com/cyberroadie/varnish-urlsort
And a blogpost describing it here:
http://cyberroadie.wordpress.com/2012/01/05/varnish-reordering-query-string/
Is it possible to get it li
In message , Artur Bergman
writes:
>> You mean a 503 ? Same is in my proposal from yesterday: You get
>> into vcl_fetch{} with a synthetic 503 response
>>
>> In some ways this way of doing things is cleaner, but I fear also
>> more confusing.
>
>No, I mean vcl_fetch returns something that you
On Jan 14, 2012, at 11:27 AM, Poul-Henning Kamp wrote:
> You mean a 503 ? Same is in my proposal from yesterday: You get
> into vcl_fetch{} with a synthetic 503 response
>
> In some ways this way of doing things is cleaner, but I fear also
> more confusing.
No, I mean vcl_fetch returns someth
In message <674c6610-199b-43b7-874e-7113361b4...@crucially.net>, Artur Bergman
writes:
>> 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 ?
>
>What happens
On Jan 14, 2012, at 11:07 AM, Poul-Henning Kamp wrote:
>> Couple of points.
>>
>> I agree with all, except I think they should be delivered through =
>> vcl_deliver, or you have to duplicate header logic in both of them.
>
> Presently we allow limited obj.* access in vcl_deliver{}, but that's
>
In message <4f118990.7020...@uplex.de>, Geoff Simmons writes:
>On 1/13/12 2:18 PM, Poul-Henning Kamp wrote:
>>
>> By default all backend fetches which can find a candidate for it,
>> will try to IMS against the backend. If you do not want that, you
>> remove the bereq.http.IMS header in vcl_pa
In message <5ebb67dc-b916-4bc2-9c9a-10205edf7...@crucially.net>, Artur Bergman
writes:
>Couple of points.
>
>I agree with all, except I think they should be delivered through =
>vcl_deliver, or you have to duplicate header logic in both of them.
Presently we allow limited obj.* access in vcl_del
On Jan 13, 2012, at 5:18 AM, Poul-Henning Kamp wrote:
> In vcl_fetch{} we add a "BOOL fetch_body()" function, so that you
> can insist on pulling the entire object from the backend, before
> accepting it into the cache, before deciding to deliver it to
> the client, or for doing (vmod-) modificat
In message <1326563395-8543-1-git-send-email-git...@bsdchicks.com>, Rogier 'Doc
Wilco' Mulhuijzen writes:
>diff --git a/bin/varnishd/cache/cache_center.c
>b/bin/varnishd/cache/cache_center.c
>index 4967c82..1b62937 100644
>--- a/bin/varnishd/cache/cache_center.c
>+++ b/bin/varnishd/cache/cache_ce
---
bin/varnishd/cache/cache.h | 12 +---
bin/varnishd/cache/cache_center.c |6 ++--
bin/varnishd/cache/cache_shmlog.c |4 +++
bin/varnishd/cache/cache_vrt_vmod.c |2 +-
bin/varnishd/mgt/mgt.h |4 ++-
bin/varnishd/mgt/mgt_param.c|2 +-
bi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/13/12 2:18 PM, Poul-Henning Kamp wrote:
>
> By default all backend fetches which can find a candidate for it,
> will try to IMS against the backend. If you do not want that, you
> remove the bereq.http.IMS header in vcl_pass{}/vcl_miss{}
Wh
12 matches
Mail list logo
