httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <>
Subject AW: ssl_io_filter_output vs EOC
Date Mon, 06 Feb 2017 11:53:40 GMT

> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic []
> Gesendet: Freitag, 3. Februar 2017 18:06
> An: httpd-dev <>
> Betreff: ssl_io_filter_output vs EOC
> Besides metadata buckets, should the EOC semantic really apply to the
> ssl output filter?
> It's not really an issue by now because we never send "data" buckets
> after an EOC, but should this happen do we really want to send them
> out in clear, after the TLS close notify?
> I'd rather be safe here and return an error up the filters' stack.
> Actually this is what is done already if the data come in the same
> brigade as the EOC (ssl_filter_write() in the same loop will fail when
> the TLS connection is shutdown), but for subsequent brigade(s) we'd
> pass through (per EOC semantic).
> This at least requires a consistency "fix" (for the theory, I can't
> think of any pratical/reasonable use of data buckets after EOC, e.g.
> an Upgrade from TLS to clear looks really hazardous...).
> Is it unacceptable to add an exception to the EOC semantic (for data)
> here and fail (as sanity check)?

IMHO we currently fail after we processed an EOC (no matter if in the same brigade or in a
follow up brigade)
and we should continue doing so.


View raw message