Re: Sending multiple responses

2003-11-08 Thread amit athavale
>>I observed one more thing :  Filters such as http_header_filter removes itself from 
>>filter chain by calling "ap_remove_output_filter". So  this filter should take care 
>>that if I am sending 1xx kind of responses it should not remove it from chain, else 
>>in subsequent responses there are no headers.
>
>Of course.  The best-case is to put this in the HTTP filter itself, I'm guessing.

By HTTP filter do you mean core_output_filter or something ?


>>I hope there would be more cleaner way of doing it somewhere in future. :)
>
>Apache 2.1 is in development, and has a number of new-feature changes like
>SSL/TLS connection upgrade.  This should be written against and committed
>to the new codebase, and may be backported if it doesn't break compatibility
>between 2.0 releases.
>
>I'll sketch something up today for you to play with.


I would love to play with that :) 


Thanks a lot,
Amit






Enter now for a chance to win a 42" Plasma Television!
http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda1.com/1/c/563632/113422/313631/313631
AOL users go here: 
http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda1.com/1/c/563632/113422/313631/313631
This offer applies to U.S. Residents Only


Re: Sending multiple responses

2003-11-07 Thread William A. Rowe, Jr.
At 12:38 AM 11/7/2003, amit athavale wrote:
>Thanks Bill for the reply.
>
>My 2 cents (I am filter novice :) )
>
>>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.
>
>I observed one more thing :  Filters such as http_header_filter removes itself from 
>filter chain by calling "ap_remove_output_filter". So  this filter should take care 
>that if I am sending 1xx kind of responses it should not remove it from chain, else 
>in subsequent responses there are no headers.

Of course.  The best-case is to put this in the HTTP filter itself, I'm guessing.

>>It's a very interesting request, thank you for posting it to the list, Amit!
>
>Actually it will become necessary when mod_dav will be pushed more into commercial 
>arena. COPYing large collection etc are normal operations and often clients sets 
>time-out of 120sec or so. Its necessary from UI perspective (could show progress bar 
>etc.).

I have no doubt, there are occasional; complains about long-running cgis and
so forth timing out on the connection before the request is serviced.  Cranking
the timeout to 5 minutes isn't a healty solution, as another thread on this
list points out.

>I hope there would be more cleaner way of doing it somewhere in future. :)

Apache 2.1 is in development, and has a number of new-feature changes like
SSL/TLS connection upgrade.  This should be written against and committed
to the new codebase, and may be backported if it doesn't break compatibility
between 2.0 releases.

I'll sketch something up today for you to play with.

Bill 



Re: Sending multiple responses

2003-11-06 Thread amit athavale
Thanks Bill for the reply.

My 2 cents (I am filter novice :) )

>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.

I observed one more thing :  Filters such as http_header_filter removes itself from 
filter chain by calling "ap_remove_output_filter". So  this filter should take care 
that if I am sending 1xx kind of responses it should not remove it from chain, else in 
subsequent responses there are no headers.


>
>It's a very interesting request, thank you for posting it to the list, Amit!


Actually it will become necessary when mod_dav will be pushed more into commercial 
arena. COPYing large collection etc are normal operations and often clients sets 
time-out of 120sec or so. Its necessary from UI perspective (could show progress bar 
etc.).

I hope there would be more cleaner way of doing it somewhere in future. :)

Thanks a lot
Amit




FREE ADHD DVD or CD-Rom (your choice) - click here!
http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda2.com/1/c/563632/131726/311392/311392
AOL users go here: 
http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda2.com/1/c/563632/131726/311392/311392
This offer applies to U.S. Residents Only


Re: Sending multiple responses

2003-11-06 Thread William A. Rowe, Jr.
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 = 1. 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



Sending multiple responses

2003-11-05 Thread amit athavale
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 = 1. 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.

Could somebody please suggest me how this can be done in clean way ?

TIA
Amit



FREE ADHD DVD or CD-Rom (your choice) - click here!
http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda2.com/1/c/563632/131726/311392/311392
AOL users go here: 
http://ad.doubleclick.net/clk;6413623;3807821;f?http://mocda2.com/1/c/563632/131726/311392/311392
This offer applies to U.S. Residents Only