In no particular order, from person-to-person discussions over the past week; to those who are against the state structure, let me offer that I've suggested the alternative of a sub-connection. Now that may not be the answer, but realize that, just as we _must_ have sub-requests to do anything useful in the apache http server, other protocols will require sub-connections. It's a stateful mess. About request_rec comments; The answer isn't to deny all of the very useful information in connection and request records to other protocols. FTP maps quite well to a bunch of extra information we collect in the context of http. The problem is mapping the info we collect into feedback that is meaningful to the protocol at hand. I'd hate for module authors to reinvent the wheel for every protocol they wish to support. About the security aspect; For the limited security scope, I've suggested we have a chain of auth structs, that each type/value that is negotiated is tacked on, and torn down as the user leaves a given connection or sub-connection. E.g. their IP address becomes an identity record, their SSL sig becomes the next identity record, and finally the basic auth that the resource required becomes the final identity record. This would allow us to have very stateful information, in a very dense format, across a number of negotiations. [http suffers from this as well, if using NTLM auth.] And in general; If we get this all right, https over http [upgrade connection] will fall right into place. If not, we know we blew it :-( Let's try to get resource-oriented requests (e.g. scheme://server/resource) into the same general schema so that the ftp/http/https details can be as transparent as authors desire. I'm not writing to the non-resource requests (e.g. smtp and that ilk) since those will follow an entirely different state and service model. I'm only arguing that similar service models should be interchangable, even if the state model changes. Bill
