I wasn't using ap_send_interim_response, though I'll take a look at it. I just used the code previously posted on this thread, copied straight from http_filter's sending of 100 Continue responses. And it works just fine as is. :-)
As for Joe's question, I don't have a patch that fixes things, but rather the contrary: I had to remove a patch I had added that broke things. Specifically, I had added a 103 entry to status_lines in http_protocol *without* updating the LEVEL[2-5]00 #defines, which led ap_index_of_response to use my new 103 instead of a 200, completely confounding my ability to decipher what was going on, since I thought that the 103 was coming from my own code (which it wasn't as my filter wasn't properly loaded). In other words, I had created a false trail which was becoming increasingly difficult to follow, because I was misparsing the output it generated. Charles On Feb 8, 2008 12:03 PM, Nick Kew <[EMAIL PROTECTED]> wrote: > On Fri, 8 Feb 2008 11:46:18 -0500 > "Charles Fry" <[EMAIL PROTECTED]> wrote: > > > All right. I finally resolved this, and it ends up the code works just > > fine, it's just that the input filter wasn't set properly, but I > > didn't notice due to the spurious 103 I was observing due to my > > modification of http_protocol. Whew. > > Great. Saves thinking about whether I'd have anything useful to say. > > Are you using the (new) ap_send_interim_response API function, > or is the response embedded in your filter? > > -- > Nick Kew > > Application Development with Apache - the Apache Modules Book > http://www.apachetutor.org/ >
