12:44 AM 11/6/2003, amit athavale wrote: >Hi, > >Requirement : >--------------- > >I want to change the mod_dav code so that it sends "102 Processing" responses after >copying say 5 resources. This is necessary when COPYing or DELETEing large >collections.(say depth > 20 and total resources = 10000. In such cases webdav clients >times-out but server continues to process . This might be confusing for the user. > >Issue : >--------- >How can I use apache APIs/filter APIs so that from "handler" it'll continue to send >"102 Processing" responses and after everything is deleted, it will send "204" as >usual and come out of handler. > >Looking at the code I can think of the ugly way of doing it by writing response using >ap_r* and simulate the behavior of finalize_request_protocol and >check_pipeline_flush. (and then reset r->eos_sent to 0) > >I know this is not the clean way of doing it but couldnt come up with it.
The clean way, I just realized, doesn't exist today. The logical way at the moment is to take your filter* chain, and walk it until you get past the content. But you also need to walk past the http filter so that it isn't considered part of the 'body'. No further, because if there was a transfer encoding schema going on, you would need this compressed, and you want it ssl crypted if mod_ssl is in the loop. Never mind that additional http protocol data may be required, and that your answer is *wrong* if someone has plugged in an alternate transport in place of HTTP/1.1. (It would even be wrong for HTTP/1.0 responses.) So I think this is only 1/2 an answer. You are sending a response, so it should be sent down the filter chain. But it isn't body, it's metadata. Filter gurus know where I'm going with this ... We need to create a new metadata bucket to pass on the Continue, or Processing, or other 1xx-style response codes. It needs to be processed by the HTTP filter so that these responses aren't inserted into 1.0 streams, or into the middle of a chunked response, etc. An interesting side effect - should this be passed to the head of the filter stack (in which case *every* filter needs to pass it immediately even if that filter hasn't composed it's next content bucket), or should we have some accessor ap_pass_protocol_brigade that skips the content/body filters? It's a very interesting request, thank you for posting it to the list, Amit! Bill
