Robert, I didn't see my request on your list. I was hoping that when a Session directive is not provided, and random back-end selection is used, pound would try to re-use back-end for requests made on HTTP keep-alive connection. For example, if a client makes a request for a web page, and then subsequent requests for images/css/js, I'd like to have an option to tell pound to reuse the original backend on its original connection (for that client's request). Currently, when the subsequent requests come in, pound randomly selects a new backend. If its a different back-end, it disconnects, and connects to the new machine, and continues this cycle (where the original backend might be chosen again). For this reason, to cut down on the number of connects/disconnects, we use IP Session type, to "bind" a client's request to a specific server. This leads to other problems, like worse distribution, as randomness is now based on the client's IP addresses.
Also, this week we've been dealing with a client who claims they've made requests to us, but I couldn't account for them. After looking in log files for specific time of the request, I found the errors in our LOG_NOTICE log file. Client's IP address wasn't logged, and because it was a POST, it was difficult to find the request. I'd like to see better error reporting. If pound encounters a problem with a backend during a transaction, it logs a message in LOG_NOTICE, and doesn't log the response like it would after a normal response. This leads to problems when a client reports an error, but the request can't be found in normal log files. I'd like to see couple of improvements in this area: 1. Better/consistent information logged for the error in LOG_NOTICE - perhaps all of the fields covered by regular logging (LogLevel=1) plus the error message. 2. Log the response in LOG_INFO. This is very important, as it would make sure all of the requests are account for in the log files. Thanks. Albert On 2/4/2012 11:50 AM, Robert Segall wrote: > So here is a summary of all the feature requests I have seen until now, > as well as some comments on my part: > > * protocol selection (SSL v2/v3/TLS)/Martin Meredith > good idea - accepted for 2.7 > > * thread load instrumentation/Leo > accepted for 2.7 > > * dynamically growing number of threads/Leo > I don't really see what do you gain by it. Care to clarify? > > * detect -Wno-unused-result support/Joe Gooch > already done - will be in 2.7a (slipped out of 2.6 by mistake) > > * dynamic back-end address (DNS) or change via poundctl/Rob Moore > we'll need to look at how complex the implementation is > for regular back-ends probably OK, for SSL may be a little tricky > probably OK for 2.7 > > * SSL Ciphers (BEAST)/Joe Gooch > accepted for 2.7 > > * Client Renegotiation/Joe Gooch > accepted for 2.7 > > * SSLv2 should be disabled by default/Joe Gooch > superseded by protocol selection > > * CSRF issue w/ invalid tags/et al in redirects/Joe Gooch > accepted for 2.7 > > * config reload/Erik Hensema > not as easy as it looks - suggestions are welcome > > * session cookies by Pound/Francisco Ruiz > needs more discussion. It would break the proxy transparency > > * enhanced alive test: 200/503 reply rather than connect/Francisco Ruiz > needs more discussion. Can be easily supported now via external > scripts, so it's not clear we need it > > * include file, include dir/Joe Gooch > include file is already supported > include dir is dangerous, as the file inclusion order is unpredictable > - rejected > > * ForceHTTP10/ssl unclean shutdown functionality based on user agent/Joe > Gooch > needs more analysis, but looks OK > > * Socket ownership and permissions/Joe Gooch > accepted for 2.7 > > * PCRE-based dynamic redirects/Joe Gooch > needs more analysis > > * NoSSL redirect/Joe Gooch > I think it is (mostly ?) supported by existing redirect mechanism > > * back-end clusters/Todd Freeman > can be done via multiple includes of same file - rejected > > Please feel free to comment on the above, or any other features I > missed.
