Le (On) Tue, Apr 03, 2012 at 07:45:03AM +0200, Baptiste ecrivit (wrote): > Hi, > > May I ask you why you want absolutely not hash this part? > I clearly don't understand, and I don't see any disadvantage of > hashing a full URI.
The full URI includes informations (like a key for instance) that shouldn't be hashed since I want to maintain a specific cache affinity based on a certain part of the URI. I understand this is not possible to do easily, and I just find it weird since haproxy is full of powerful regexps, but that's fine, I can hash according to the first 3 characters of the URI, it's just not elegant. Cheers, > On Mon, Apr 2, 2012 at 8:28 PM, Sameh Ghane <[email protected]> wrote: > > Le (On) Mon, Apr 02, 2012 at 06:32:31PM +0100, Jonathan Matthews ecrivit > > (wrote): > >> On 2 April 2012 17:25, Sameh Ghane <[email protected]> wrote: > >> > > >> > Is there anything I missed ? Like setting a specific request header > >> > which would > >> > be the result of a regexp on the URI, and balancing on that header ? > >> > >> I don't understand what you've written. Could you say it again, but > >> differently? > >> Some examples would probably help too. > > > > Sorry for this. > > > > Imagine I see requests for /xxxxx/yyyyyy.zzzzz and I would like to balance > > according to the URI, though I don't want the "yyyyy" part to be fed to the > > hash > > function. As far as I understand, it cannot be done with 'balance uri'. > > > > That's why I would like to know if it can be circumvented through something > > like: > > > > backend be > > .. > > reqadd  balhdr:\ xxx > > balance hdr(balhdr) > > .. > > > > > > Cheers, > > > > -- > > Sameh Ghane > > -- Sameh Ghane
