On 09/13/2009 02:19 PM, Graham Leggett wrote: > Ruediger Pluem wrote: > >> The comment complained about talking to the client via direct socket >> communication which is somehow understandable. Using the connection wrapper >> for the >> backend communication is already a very hacky (albeit working) approach >> in the current proxy code that was needed to avoid redoing all the HTTP code >> work >> that was already there. It created several problems. > > Problems like? > > The use of the connection in the HTTP proxy code is a prerequisite for > supporting SSL to a backend server.
As said there was no alternative as we had and have no SSL aware HTTP client library in httpd. The problems are pool and bucket allocator lifetimes when using pooled backend connections and running things like the pre connection hook that confuse other modules using this hook because they think a new client connection hit httpd. > >> As we do not need any protocol filtering or anything else when talking to >> the backend >> but just a plain socket communication I see no reason why we should make the >> code more >> complex as needed and get all the downsides of the connection wrapper for >> the backend >> communication. > > Downsides like? See above. It also adds overhead that is not needed here without adding benefit. > >> And BTW, we still fiddle directly with the socket (client and backend) by >> doing a >> poll on them. Mixing connection and poll really looks ugly to me :-). >> If you want to work with brigades and buckets in the code just create a >> socket bucket >> for the backend connection. > > Communication is bidirectional, so we have to watch both connections > simultaneously. How does using a socket bucket solve this? It doesn't. Using the socket bucket just gets you around calling the recv functions like in the old code. You can work with apr_bucket_read and alike if you see this as more beneficial for whatever reason compared to the recv calls. Regards Rüdiger
