On Fri, 2005-02-11 at 01:34 -0800, Greg Stein wrote: > Um... no. Why would somebody need to do that? In my experience, you might > run a sub-request. But you do *not* construct request_rec objects out of > the blue.
Unless one wants to run a "canned" sub-request (through the use of some other functions), this function (and some others) is required for sub- requests as well. If "canned" sub-request functions are used, "custom" sub-request functionality is difficult to achieve without not so nice workarounds. I'm not sure why constructing a request would be so unusual. Application servers running inside Apache may need to do this stuff all the time. > Can you explain your use case? Why do you need that function? The new request hits an authentication URI, thus authenticating the user without the need to supply authentication headers (of basic authentication) on every request (in fact - ever). The result of authentication is stored in the application's session store for further use. I can see instances where one would run a request internally, get the result and include (parts of it) in the response. > I've said before: mod_perl is a poor example. It is too invasive with our > APIs. And if it is referring to one of those functions via defining > CORE_PRIVATE, then it rightly deserves a thrashing. OK, maybe. But there are plenty of other modules inside Apache distro itself that use CORE_PRIVATE stuff too. This comes to my original question - what is really considered "public API"? -- Bojan
