httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: r1470679, async write completion, non blocking writes, and mod_ssl
Date Sun, 04 Aug 2013 22:37:57 GMT

On 04 Aug 2013, at 8:52 PM, Stefan Fritsch <sf@sfritsch.de> wrote:

> Hi,
> 
> I did some testing/reviewing of the ssl/event backport proposal
> 
>  * core, mod_ssl: Lift the restriction that prevents mod_ssl taking
>    full advantage of the event MPM. Enable the ability for a module
>    to reverse the sense of a poll event from a read to a write or
>    vice versa.
> 
> The general idea of the patch is good. Unfortunately, the current 
> version doesn't have much effect. The problem is that the core output 
> filter, which does all the decisions about buffering, flushing, 
> blocking, and async write completion, comes after the ssl output 
> filter. Therefore core_output_filter only sees encrypted data and 
> never sees file buckets. Therefore it will only do async write 
> completion if the encrypted data left to send for a request is less 
> than THRESHOLD_MAX_BUFFER (64k).
> 
> To be more efficient the order of the filter doing the 
> buffering/flushing decitions and the ssl output filter would have to 
> be reversed. I haven't looked how this could be achieved. Maybe 
> mod_ssl would have to do its encryption in a AP_FTYPE_NETWORK filter 
> that comes after the core_output_filter().
> 
> Does it make sense to backport the current state nonetheless? While it 
> seems likely to me that the current API would be sufficient even if 
> this issue is fixed, it may be prudent to wait with a backport until 
> we know how the issue should be fixed exactly.

Are you seeing a specific problem?

The way openssl's async behaviour works, is that is the middle of a read, openssl might need
to write, and in the middle of a write, openssl might need to read. Openssl tells you this
through the codes SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE. You receive these codes, re-run
the select or poll or whatever with the sense that openssl has asked for, and you're done.
It is that simple.

Sure, httpd might do all sorts of buffering of reads and writes, but at the end of the day
it won't matter, because openssl will never attempt to write-during read or read-during-write
without asking you whether it is ok first.

I can see a potential problem if the core decided to buffer a write, but in theory that could
be solved by mod_ssl simply sending a flush bucket down the stack whenever the sense changes.
I don't see why the core needs to care that the data is a file, or encrypted, or whatever,
the core should just do what the core does.

Regards,
Graham
--


Mime
View raw message