, in need
of best performance and flexibility.
--
Mit freundlichen Grüßen
Reiner Karlsberg
Ringerottstr. 50
45772 Marl
Germany
Tel.: (+49) (0)2365-8568281
Mob.: (+49) (0)1788904200
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4570 / Virus Database: 3986/7831
, Alex should have a definite answer.
--
Mit freundlichen Grüßen
Reiner Karlsberg
Ringerottstr. 50
45772 Marl
Germany
Tel.: (+49) (0)2365-8568281
Mob.: (+49) (0)1788904200
-
This eMail does not contain any virus.
Von AVG überprüft - www.avg.de
Version: 2012.0.2242 / Virendatenbank
change the picture.
For this, splitting the very large object in a few parts using some squid.conf-parameter like max_cached_range_size,
together with storeID-rewrite, might be an acceptable compromise.
--
Mit freundlichen Grüßen
Reiner Karlsberg
Ringerottstr. 50
45772 Marl
Germany
Tel
any ideas? I was thinking of asking the varnish developers about their
approach to the subject.
Anorher issue is that the cache object id (store-id)is decided before any
response is being recived from the server.
The problem you presented here, assuming, you are pointing at range
Am 30.01.2013 14:11, schrieb Eliezer Croitoru:
What I was pointing about the store-id being decided before getting any data is
for what i'm about to write.
What happens in a case when a user requests partial content and the server
denies it and returns full response? squid
cache that or not?
I am new here, so please be kind :-)
But I am not new to the handicraft of programming. So, after spending a few days starting to dig into rather new source
code regarding Rock, the beginning of an old fairy tail came to my mind:
Once upon a time, when there was no object oriented language
Am 29.01.2013 21:21, schrieb Alex Rousskov:
I find it interesting that squid.conf.documented does not document
default case sensitivity. Perhaps we can use that to justify making
everything sensitive by default?
YES.
Applaus. Compliments. Only waited for this suggestion :-)
That really makes