Re: Cookie inspection

2007-05-29 Thread Dag-Erling Smørgrav
Omar Kilani [EMAIL PROTECTED] writes:
 I'd like to modify req.hash in vcl_hash to take into account the value
 of this particular cookie [...]
 From looking through the varnish-cache code, I don't think this type
 of operation is supported, and I'm not sure what the best way to
 represent this in VCL is.

Poul-Henning is working on making multi-value headers accessible as
associative arrays, e.g. req.http.cache-control[max-age] for
Cache-control: max-age.  This implies not only inspection but also
modification of individual fields.  Your patch is a step in the right
direction, though it probably duplicates (or conflicts with) part of
Poul-Henning's work.

In any case, could you please open a ticket with the patch as an
attachment?

 Doing something like req.http.Cookie.LANGUAGE *could* theoretically do
 the right thing (and use http_GetHdrField, although some browsers can
 send multiple values for the same cookie name... :)

AFAIR from RFC2616, if multiple values are provided for the same key,
only the last one applies.

DES
-- 
Dag-Erling Smørgrav
Senior Software Developer
Linpro AS - www.linpro.no
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Cookie inspection

2007-05-29 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Omar
 Kilani writes:

Including the entire req.http.Cookie in the hash key is suboptimal as
there are a bunch of other cookies set (session cookies, etc)
depending on other variables.

Doing something like req.http.Cookie.LANGUAGE *could* theoretically do
the right thing (and use http_GetHdrField, although some browsers can
send multiple values for the same cookie name... :) and *looks* right,
but obviously has a very different meaning in VCL where it compiles
to:

The Planned syntax is:
req.http.Cookie[language]

and just as for http headers, the headers will be read sequentially
and the last found value is used.

http://treehou.se/~omar/cookie-inspection-1.patch

Not bad :-)

The other thing I'd like to be able to do is have some sort of 'first
match over an array of header values' VCL construct, so you could vary
the hash by whatever languages in Accept-Language your site supports

Does your backend include a proper Vary: header when it selects on
language ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


My Varnish project

2007-05-29 Thread admin
Hello,

Thank you very much for an excellent product.  I wish to use Varnish
cache as a front end to my system, but I have some problems in using it,
and the way forward probably involves hacking the code. I will run this
past you all first to get your opinion.



Background:

Our site (http://www.adofms.com.au) is a traditional LAMP application,
using PHP / Apache / MySQL.  Users login to the application, and upon
login, a session is created in the database, and a cookie is set for the
user.

The ADOFMS system contains a large number of Units - Fuel Card -
Vehicles for the users to maintain. When a user logs in and gets a valid
session, they can only see the vehicles and cards associated with their
unit. So far so good.

Problem that I have is that the session identification is done entirely
by the cookie - I do not repeat the session ID in the URL.

So for example -

User number 1 visits :
http://www.adofms.com.au/vehicles.php   - and gets a list of vehicles
that they own.

User number 2 visits
http://www.adofms.com.au/vehicles.php - and they get a different list of
vehicles to what user 1 sees.

So, of course, with Varnish, the vehicles.php output from user 1 is
cached, and presented to user 2. This is very quick and efficient, but
not what we want. I need things to be cached on a session by session basis.


I believe I have 3 options here :

1) Re-write the whole PHP application to repeat the session ID as part
of every URL in the system. That is do-able, but boring.

2) Cook up some VCL code to cache pages on a per-session basis, by
appending the req.http.Cookie value to the URL before it is stored in
the cache, and then doing the same thing when looking up the cache. VCL
does not easily allow this to happen though  Correct me if I am wrong.

3) Hack the source code of Varnish to use the session ID (from the
cookie) to segregate cached results by session.


I am going to have a go at method 3) anyway, but would like your opinion
before starting out on this adventure  :)   I would think its not too
hard, since I know exactly what I am trying to achieve, which is often
half the battle when coding. I have some similar enhancements that would
suit my application well. I will explain them here:

Example for extra enchancement :

I have a URL such as

http://www.adofms.com.au/vehicles.php?op=viewid=12345
  - Displays the full details of vehicle ID 12345, which can generate a
lot of SQL calls to create. I would love to cache the results of this on
a per user basis.

If the user updates the vehicle - the naming conventions in this
application guarantee that the backend receives a HTTP POST request with
a URL of :
http://www.adofms.com.au/vehicles.php?op=update .. followed by a call to
redisplay the record, which in this case is
http://www.adofms.com.au/vehicles.php?op=viewid=12345refresh=1

Now - If I am going to hack the Varnish code anyway, I can get around
this by intercepting POST requests that have an op=update GET variable
set, and an id=some value POST variable set .. and if so, remove the
existing vehicles.php?op=viewid=some value   entry from the cache.

Again, running this idea past you for feedback. I understand that such a
change would be very specific to our application and the way it works,
but thats OK with me.

Another alternative would be to make VCL a little more powerful - a
couple of simple ways of changing the key value for the obj variable
would go a long way I think .. and the ability to grab GET and POST
variables would be very handy too.


Would appreciate your thoughts on these issues.

Thank you
Steve OConnor
ADOFMS Chief Developer

___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: My Varnish project

2007-05-29 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], admin writes:

2) Cook up some VCL code to cache pages on a per-session basis, by
appending the req.http.Cookie value to the URL before it is stored in
the cache, and then doing the same thing when looking up the cache. VCL
does not easily allow this to happen though  Correct me if I am wrong.

Actually, we just added a facility to do this:

vcl_hash {
req.hash += req.http.cookie;
}

It will (not yet) do the right thing if there are multiple cookie
header lines, but that is in the works.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: My Varnish project

2007-05-29 Thread ADOFMS Admin, SteveOC
Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], admin writes:
   
 Poul-Henning Kamp wrote:
 

   
 The man pages for VCL do mention a vcl_hash interface, but it says it's
 not implemented yet. Wasnt sure what it was, but I assume that is called
 whenever the hash value for the key of the object is calculated ? 
 

 Yes.

   
Thanks

I have this now :
 sub vcl_hash {
 req.hash += req.http.cookie;
 }

and get this when I run varnishd :

(/etc/varnish/adofms.vcl Line 22 Pos 14)
 req.hash += req.http.cookie;
-

I think I need a more up to date source file ?

When I emerge varnish , it fetches and builds :
mirror://sourceforge/varnish/varnish-1.0.4.tar.gz

Is there a newer version in SVN or something ?


___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: My Varnish project

2007-05-29 Thread Dag-Erling Smørgrav
ADOFMS Admin, SteveOC [EMAIL PROTECTED] writes:
 I have this now :
  sub vcl_hash {
  req.hash += req.http.cookie;
  }

 and get this when I run varnishd :

 (/etc/varnish/adofms.vcl Line 22 Pos 14)
  req.hash += req.http.cookie;
 -

 I think I need a more up to date source file ?

You need the latest sources from Subversion, and you left out the set
keyword.

DES
-- 
Dag-Erling Smørgrav
Senior Software Developer
Linpro AS - www.linpro.no
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Cookie inspection

2007-05-29 Thread Omar Kilani
On 5/29/07, Poul-Henning Kamp [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED], Omar
  Kilani writes:

 Doing something like req.http.Cookie.LANGUAGE *could* theoretically do
 the right thing (and use http_GetHdrField, although some browsers can
 send multiple values for the same cookie name... :) and *looks* right,
 but obviously has a very different meaning in VCL where it compiles
 to:

 The Planned syntax is:
 req.http.Cookie[language]

 and just as for http headers, the headers will be read sequentially
 and the last found value is used.

That makes a lot more sense. :)

Out of curiosity, are things like this documented on Trac or somewhere else?

I probably missed it searching the tickets - has this work been started?

 http://treehou.se/~omar/cookie-inspection-1.patch

 Not bad :-)

Hehe - I really just meant to illustrate what I was getting at with
the patch. ;)

It took longer to write the email than to code up the patch, which I
think says a lot about the hackability of the code and how easy it is
to understand.

 The other thing I'd like to be able to do is have some sort of 'first
 match over an array of header values' VCL construct, so you could vary
 the hash by whatever languages in Accept-Language your site supports

 Does your backend include a proper Vary: header when it selects on
 language ?

Yes, but I'm not sure how Vary on Accept-Language is supposed to work
- does it just add the entire value to the hash key or?

Wouldn't the hit rate be low on the cached content if this was the case?

For example, I'd serve en-US to all these browsers (whose language
settings I haven't changed):

Opera (which sends the following Accept-Language value):

en,ja;q=0.9,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.5,nl;q=0.4,sv;q=0.3,nb;q=0.2,da;q=0.1,fi;q=0.1,pt;q=0.1,lv;q=0.1,zh-CN;q=0.1,zh-TW;q=0.1,ko;q=0.1,en;q=0.1

Safari:

en

Camino:

en,ja;q=0.9,fr;q=0.9,de;q=0.8,es;q=0.8,it;q=0.7,nl;q=0.6,sv;q=0.6,nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,lv;q=0.3,zh-Hans;q=0.2,zh-Hant;q=0.1,ko;q=0.1

But would they all be cached independently and served different
versions of the same document?

Thanks.

Regards,
Omar
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc