Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 174.143.229.200 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: r1470679, async write completion, non blocking writes,
 and mod_ssl
From: Graham Leggett <minfrin@sharp.fm>
In-Reply-To: <1965246.dTmAyLRneo@k>
Date: Mon, 5 Aug 2013 00:37:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7A11067-2DC1-47B9-BEB0-A78996BC9CC9@sharp.fm>
References: <1965246.dTmAyLRneo@k>
To: dev@httpd.apache.org


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

> Hi,
>=20
> I did some testing/reviewing of the ssl/event backport proposal
>=20
>  * 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.
>=20
> The general idea of the patch is good. Unfortunately, the current=20
> version doesn't have much effect. The problem is that the core output=20=

> filter, which does all the decisions about buffering, flushing,=20
> blocking, and async write completion, comes after the ssl output=20
> filter. Therefore core_output_filter only sees encrypted data and=20
> never sees file buckets. Therefore it will only do async write=20
> completion if the encrypted data left to send for a request is less=20
> than THRESHOLD_MAX_BUFFER (64k).
>=20
> To be more efficient the order of the filter doing the=20
> buffering/flushing decitions and the ssl output filter would have to=20=

> be reversed. I haven't looked how this could be achieved. Maybe=20
> mod_ssl would have to do its encryption in a AP_FTYPE_NETWORK filter=20=

> that comes after the core_output_filter().
>=20
> Does it make sense to backport the current state nonetheless? While it=20=

> seems likely to me that the current API would be sufficient even if=20
> this issue is fixed, it may be prudent to wait with a backport until=20=

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