httpd-dev mailing list archives

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


> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic [mailto:ylavic.dev@gmail.com]
> Gesendet: Freitag, 3. Februar 2017 18:06
> An: httpd-dev <dev@httpd.apache.org>
> 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.

Regards

Rüdiger
Mime
View raw message