On Mon, May 11, 2020 at 06:38:40PM +0300, Dmitry Belyavsky wrote:
> Dear Tomas,
>
> I'm not sure this is the best possible solution because it makes the
> application developers doing extra compile-time checks.
This is a very minimal change they they need to do that doesn't
have much risk.
But
Dear Tomas,
On Mon, May 11, 2020 at 2:07 PM Tomas Mraz wrote:
> On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote:
> > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > > > On 07/05/2020 12:22, Kurt Roeckx wrote:
> >
On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > > So I think we need at least to agree on:
> > > > - Do we want an
On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote:
> On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote:
> >
> > So I think the suggestion is to have this:
> > - By default, SSL_ERROR_SSL is returned with
> > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
> > marked
Dear Kurt
On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > >
> > > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > > So I think we need at least to agree on:
> > > > - Do
On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> >
> > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > So I think we need at least to agree on:
> > > - Do we want an option that makes the unexpected EOF either a fatal
> > >
On 07/05/2020 20:28, Dmitry Belyavsky wrote:
> From my point of view, if we don't revert the change for the sake of API
> clarity, we need to provide an option restoring old behaviour at least
> for test purposes.
Presumably nginx can already handle the situation where a close_notify
*is*
Hello,
I want to draw everybody's attention to the position (and argumentation) of
Nginx developers:
===
As already mentioned by Dmitry, we here at nginx don't think the change was
necessary. As Matt already said above in the comments to SSL_CONF_cmd.pod
change, the error was always
On Thu, 2020-05-07 at 15:45 +0200, Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote:
> > Actually the coincidence is that the errno is set to 0 on EOF. So
> > yes,
> > we should explicitly clear the errno on EOF so any leftover value
> > from
> > previous calls does
On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote:
>
> Actually the coincidence is that the errno is set to 0 on EOF. So yes,
> we should explicitly clear the errno on EOF so any leftover value from
> previous calls does not affect this.
On EOF, errno is normally not modified. It's
On Thu, 2020-05-07 at 14:53 +0200, Kurt Roeckx wrote:
> On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote:
> > From application developer side of view for protocols that do not
> > depend on SSL detecting the truncation I think inventing a
> > different
> > behavior for this condition
On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote:
> From application developer side of view for protocols that do not
> depend on SSL detecting the truncation I think inventing a different
> behavior for this condition than the existing one as of 1.1.1f would be
> clearly wrong.
On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
>
> On 07/05/2020 12:22, Kurt Roeckx wrote:
> > So I think we need at least to agree on:
> > - Do we want an option that makes the unexpected EOF either a fatal
> > error or a non-fatal error?
> > - Which error should we return?
>
> This
On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote:
> Hi,
>
> We introduced a change in the 1.1.1e release that changed how we
> handled an unexpected EOF. This broke various software which
> resulted in the release of 1.1.1f that reverted that change.
> In master we still have the 1.1.1e
On 07/05/2020 12:22, Kurt Roeckx wrote:
> So I think we need at least to agree on:
> - Do we want an option that makes the unexpected EOF either a fatal
> error or a non-fatal error?
> - Which error should we return?
This is an excellent summary of the current situation.
I am not keen on
15 matches
Mail list logo
