On Jul 24, 2013, at 9:16 AM, Mark Harrison <m...@omniti.com> wrote: > 1) The various proxy.config.diags.output options to configure where logs go. > The defaults are sometimes not ideal and I'm always looking them up if I want > to change them. > > 2) I'm not sure there's anything that should be here, unless there are > deprecated items such as ssl.enabled that you actively want to discourage the > use of. > > 3) I usually make the following changes in my records.config. I'm not sure > they would make sense as defaults, but I'm mentioning them just in case they > do: > > proxy.config.http.insert_request_via_str INT 3 > proxy.config.http.insert_response_via_str INT 3 > > (for debugging purposes usually/making it easy for people to report issues > with caching) > > proxy.config.http.server_ports STRING 80 > > (if reverse proxy/remap_required is the default, then setting the port to 80 > might also be a sensible default) > > I always manually set proxy.config.cache.ram_cache.size, but I'm not sure > changing the default makes sense here as it's a per-system value. > > Possibly update the default SSL cipher suite to address recent-ish SSL > attacks?
Should proxy.config.ssl.server.honor_cipher_order then default to 1? > > > > > On Wed, Jul 24, 2013 at 11:46 AM, Leif Hedstrom <zw...@apache.org> wrote: > Hi all (particularly "users"), > > We'd like to get everyone's input on the records.config defaults and what > variables are in there, based on user experience. I.e. > > 1. Are there configurations that you often use, which are not in the > default records.config today? > 2. Are there configurations that are in records.config, that you feel are > so esoteric that they don't deserve to be in the default config file? > 3. Are there values that you always change, and feel we ought to modify the > defaults for? > > > Please respond to this email asap, so that we can get any such changes in to > the records.config.default.in before v3.3.5. 1) and 2) are fairly straight > forward to justify, 3) would have to be done with care (since it breaks old > behavior). > > Cheers, > > -- Leif > > > > > -- > Mark Harrison > Lead Site Reliability Engineer > OmniTI
