> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Bill Stoddard wrote: > > > This is a variation of the problem Aaron and I were interested in with > CGI scripts (and > > directly related to an open PR against 2.0.36). Unfortunately, I think > filters need some > > more work to make this possible. As Will said, we need to be able to > poll/select on both > > the frontend and backend descriptors and do the right thing. I may be > mistaken but I > > thought the proxy in 1.3 handled this correctly... > > The v1.3 proxy was always read request then read response, it never did > these two simultaneously. > > Would the changes to the filters be that drastic? We would in theory > just have to poll for incoming data (in either direction), then read > bridages from the relevant filter stack...? No...?
I tried to think through how to do this back in November, when I last touched the proxy. The easiest way to do this, is to add a new read mode to input filters, APR_READ_POLL. Each filter would be responsible for returning any data that it has if called in this mode. If none of the filters in the stack have any data, then the filter that has the socket must return the socket bucket, but it is allowed to keep a copy of the socket itself. The filter_poll call can then use apr_poll to determine which of the sockets have any data. This wouldn't be the cleanest code, but it should work. Ryan
