[Tickets #13070] Re: Deterministic Asset Names

noreply at bugs.horde.org noreply at bugs.horde.org
Sun Mar 23 11:24:05 UTC 2014


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13070
------------------------------------------------------------------------------
  Ticket             | 13070
  Updated By         | o+horde at immerda.ch
  Summary            | Deterministic Asset Names
  Queue              | Horde Base
  Version            | Git master
  Type               | Enhancement
  State              | Resolved
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


o+horde at immerda.ch (2014-03-23 11:24) wrote:

hey, thanks for the fast reply. making the path configurable is quite  
nice in it self, but i meant something slightly different.

my initial problem was the following:

i have several horde installations behind a load-balancer. this one  
uses session-binding to redirect a certain user to a certain backend.

now i tried to serve the static assets through a different pipeline  
than the rest. so i configured a reverse-proxy to deliver them. since  
its only static assets i figured i don't need the session binding and  
it can fetch the assets from an arbitrary backend.

but since the assets (e.g. compressed js files) seem to be randomly  
named, when the request for assets goes to an arbitrary backend, they  
will not match the filenames produced by the replying horde instance.

of course i could just collect all assets and serve them from a  
separate place (that's probably what i'll do), or as you suggest in  
the conf.xml place the assets directory on a nfs share. but still i  
figured it would be nice if the assets had a deterministic name, then  
this would not be necessary.

additionally it would improve cache efficiency, since random names  
also means that every asset has to be cached once per backend on a  
reverse-proxy.





More information about the bugs mailing list