httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: Sending multiple responses
Date Thu, 06 Nov 2003 18:51:04 GMT
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


Mime
View raw message