error_handler loops forever after handshake fails about via-httplib HOT 7 CLOSED

Thanks you for bringing this to my attention.
It looks like a bug in the server accept_handler: it was resetting the next_connection_ on success but not on failure...

I've changed the accept handler to reset the next_connection_ regardless and pushed the change to the develop branch. Please try it out and let me know if it's fixed the issue.

from via-httplib.

That was a very quick response, thanks!
I tested the change, but it does not appear to fix the issue.

Not sure if this helps, but I set a breakpoint in error_handler.

The first time it hits that handler, it is getting signalled from connection.hpp in this function:

static void handshake_callback(weak_pointer ptr,
                                     ASIO_ERROR_CODE const& error)
      {
        shared_pointer pointer(ptr.lock());
        if (pointer && (ASIO::error::operation_aborted != error))
        {
          if (!error)
          {
            pointer->connected_ = true;
            pointer->event_callback_(CONNECTED, ptr);
            pointer->set_socket_options();
            if (!pointer->tx_queue_->empty())
              pointer->write_data
          (ConstBuffers(1, ASIO::buffer(pointer->tx_queue_->front())));
            pointer->receiving_ = false;
            pointer->enable_reception();
          }
          else
          {
            pointer->close();
            pointer->signal_error(error);        <-- this calls the error_handler
          }
        }
      }

If I then continue, the subsequent calls to error_handler get signalled from here:

      static void write_callback(weak_pointer ptr,
                                 ASIO_ERROR_CODE const& error,
                                 size_t bytes_transferred,
                                 std::shared_ptr<std::deque<Container> >) // tx_queue)
      {
        shared_pointer pointer(ptr.lock());
        if (pointer && (ASIO::error::operation_aborted != error))
        {
          if (error)
          {
            pointer->tx_queue_->clear();
            pointer->signal_error(error); <-- this calls the error handler
          }
          else
          {
            if (pointer->disconnect_pending_)
              pointer->shutdown();
            else
              pointer->write_handler(bytes_transferred);
          }
        }
      }

from via-httplib.

Clearly my response was too quick!

You are correct that the signal_error function is called by both the handshake_callback and write_callback. However, the signal_error function calls is_error_a_disconnect to determine whether the socket should be disconnected in response to the error, because not all errors should cause a disconnect...

For SSL sockets, the is_error_a_disconnect function calls is_disconnect in the ssl_tcp_adaptor.hpp file. It is this function that determines whether to disconnect or continue. I believe that in your case, it's not recognising the SSL code(s) : asio.ssl:336130315 and asio.ssl:336462231 as errors in the line:

bool ssl_error(ASIO::error::get_ssl_category() == error.category());

Please can you set a breakpoint in is_disconnect and determine whether the ssl_error flag is being set?

from via-httplib.

Ok, so I set a breakpoint in there and I can see that ssl_error is set to 'true'.

Then it sets the ssl_shutdown flag:

 ssl_shutdown = ssl_error &&
// SSL_R_SHORT_READ is no longer defined in openssl 1.1.x
#ifdef SSL_R_SHORT_READ
               (SSL_R_SHORT_READ != ERR_GET_REASON(error.value())) &&
#endif
               (SSL_R_PROTOCOL_IS_SHUTDOWN != ERR_GET_REASON(error.value()));

          return ssl_error && !ssl_shutdown;

The ssl_shutdown flag is also true. Therefore, this function returns false.

This causes is_error_a_disconnect to call shutdown(), and return false.

from via-httplib.

Thank you for that information. I understand the issue now.

The connection is attempting to shutdown gracefully in the is_error_a_disconnect function called by signal_error. However, the connection isn't fully established at this point but the shutdown function tries to send an SSL close_notify message on the connection...

So I've removed the call to signal_error in handshake_callback and connect_callback and replaced it with calls to error_callback_ and event_callback_ to simply close the socket and remove the connection.

I've pushed the changes to the develop branch. Please try it out and let me know whether they've fixed the issue.

from via-httplib.

Thank you! This has resolved the issue.

from via-httplib.

Thank you. That's great news.
I've copied over the changes from the develop branch into master and tagged it 1.5.1.

from via-httplib.