ons 2012-09-12 klockan 10:18 +0300 skrev Eliezer Croitoru:
For the no cachable situation something should be done to lower
performance issues that could come from using store_url, some kind of
flag validation before sending it to the helper?
That only helps in the case where we know from
tor 2012-09-13 klockan 11:20 +1200 skrev Amos Jeffries:
I think long-term we want to have ICAP/eCAP generating ETag+Digest
headers for requests and responses and store using those headers as the
index key.
How do you generate an ETag from a request?
ETag is a response header, set by the
On 09/12/2012 02:50 AM, Alex Rousskov wrote:
Yes, of course. Both ICAP and eCAP have meta-headers that can go both
ways. But some people do prefer the helper simplicity, and my suggestion
was meant to give those folks a performance boost.
If the consensus is that performance-sensitive
On 12.09.2012 19:18, Eliezer Croitoru wrote:
On 09/12/2012 02:50 AM, Alex Rousskov wrote:
Yes, of course. Both ICAP and eCAP have meta-headers that can go
both
ways. But some people do prefer the helper simplicity, and my
suggestion
was meant to give those folks a performance boost.
If the
On 09/11/2012 01:08 AM, Eliezer Croitoru wrote:
On 09/11/2012 01:52 AM, Amos Jeffries wrote:
url-rewrite, store-url,
and location-rewrite (also not ported) all have the same API
This is the first time I have heard about location-rewrite and it's a
nice and interesting interface.
it can be
On 12.09.2012 09:52, Alex Rousskov wrote:
On 09/11/2012 01:08 AM, Eliezer Croitoru wrote:
On 09/11/2012 01:52 AM, Amos Jeffries wrote:
url-rewrite, store-url,
and location-rewrite (also not ported) all have the same API
This is the first time I have heard about location-rewrite and it's
a
tis 2012-09-11 klockan 15:52 -0600 skrev Alex Rousskov:
Hm... I wonder if we are making a design mistake here by following
Squid2 steps: one helper to rewrite request URL, one helper to rewrite
store URL, then one helper to rewrite some special HTTP header, etc.
Would it be better to extend
ons 2012-09-12 klockan 11:05 +1200 skrev Amos Jeffries:
However, we want also to back-port this feature into 3.2 (3.1?) and
maintain upgrade compatibility with 2.7 implementation, at least to
start with.
Do we really want to backport new features?
Regards
Henrik
On 12.09.2012 11:16, Henrik Nordström wrote:
ons 2012-09-12 klockan 11:05 +1200 skrev Amos Jeffries:
However, we want also to back-port this feature into 3.2 (3.1?) and
maintain upgrade compatibility with 2.7 implementation, at least to
start with.
Do we really want to backport new features?
On Wed, Sep 12, 2012 at 11:05 AM, Amos Jeffries squ...@treenet.co.nz wrote:
IMO the backward compatibility and easy upgrade from 2.7 overrides doing
this now. It is possible to do a migration to this design later easily
enough not to worry.
FWIW I wouldn't worry about 2.7 compat. As of
On 09/11/2012 05:15 PM, Henrik Nordström wrote:
tis 2012-09-11 klockan 15:52 -0600 skrev Alex Rousskov:
Hm... I wonder if we are making a design mistake here by following
Squid2 steps: one helper to rewrite request URL, one helper to rewrite
store URL, then one helper to rewrite some special
On 09/11/2012 05:14 PM, Robert Collins wrote:
On Wed, Sep 12, 2012 at 11:05 AM, Amos Jeffries squ...@treenet.co.nz wrote:
IMO the backward compatibility and easy upgrade from 2.7 overrides doing
this now. It is possible to do a migration to this design later easily
enough not to worry.
[snip]
12 matches
Mail list logo
