On Thu, Mar 31, 2011 at 07:58:53AM -0400, Roy Smith wrote: > Looking at the docs, I see some lines that use "option" and some that don't. > Is there a general rule as to when it should use "option"? Could you give me > a use case where you would want to apply this conditionally?
Normally "option" only refers to a boolean (hence the "no option" equivalent). But history has proven that some settings which were only boolean at some time started to receive some settings which were added there. It was a design error but now we have them. Right now I'd say : use "option" only if there is one keyword after it and if it is for a boolean setting. If some parameters are required, use something else. > As far as stripping headers, one of the problems is that the unique id > insertion happens very early, before the header capture, so the inserted id > can be logged. I took a quick look through the code right now and couldn't > find where the reqdel processing happens, but I would imagine it's after the > header capture. As I explained in another mail a few months ago, many people have many different needs on Unique IDs. Some want to reject connections which already have one, some want to keep it, some want to silently replace it, some want to have it in response too and compare request with response, then want to remove it from any response sent outside, some want to ecrypt them before passing them to a partner, etc. In order to get an idea of all possibilities, imagine an architecture where you have 6-7 layers of proxies, some under your responsibility, some under a partner's, with your internet visitors connecting to the first one and one of your partner bypassing the 2 first ones, and with your application running at the 5th one and sometimes forwarding again to a partner via the last 2 ones. When you draw that, you can better understand why there are a lot of different expectations. Regards, Willy
