httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 43738] - Who is hiding my buffered POST data from mod_ssl after renegotiation?
Date Thu, 01 Nov 2007 15:30:35 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43738>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43738





------- Additional Comments From wollman+apache@csail.mit.edu  2007-11-01 08:30 -------
What makes you say that the filter chain is correct?  I would expect the
"ssl/tls buffer" filter to be at the head to the chain, since that's where all
the data is being buffered.  There's no chance that reading from "ssl/tls
filter" will give me any data since its data has already been read and stored in
the buffer.

To answer your questions:
>- is this ap_get_client_block() call happening *before* the timeout?

Yes, I thought I made that clear in my analysis.

>- does ap_get_client_block() fail?

No, as I said before, it returns end-of-stream (0).

I haven't traced through ap_http_filter; however, in the course of instrumenting
ap_get_client_block() before I filed this bug, I made it skip over "http_in" and
read directly from "ssl/tls filter".  Same result: end of stream.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message