> > I don't see why it matters if there are redundant members in > > request_rec. However, for purity, it might be cool to divide > > request_rec up into common elements and protocol-specific stuff in a > > union. > > That's not really a problem, though of course it's hacky. It's the > logical consequence of declaring HTTPD to be multi-protocol while making > so much of it revolve around the request_rec.
Nick, in one of the background docs you sent me the 'connection filters' were described as operating outside the scope of HTTP or any request_rec. I know this is a living, changing work in progress but it seems confusing, at least to me, to shoehorn arbitrary protocols into HTTP-ish "requests". I'm having difficulty envisioning how an SMTP communication can be broken up into requests, i.e. something like HTTP requests. For example: 01 HELO joe 02 MAIL FROM:<sender1> 03 RCPT TO:<abc> 04 RCPT TO:<xyz> 05 DATA 06 ... 07 MAIL FROM:<sender2> 08 RCPT TO:<niq> 09 DATA 10 ... 11 QUIT Now how do you split this up into requests? Does 05 represent a single request, or does that DATA generate two different requests - 03 and 04 (one for each recipient)? Or is the whole thing, until 11, a single request? Perhaps the MAIL FROM's start new requests, i.e. 02 and 07 (two requests). It just seems ambiguous and difficult to justify in any way. Mind you I still might be not fully understanding Apache's request paradigm.
