Hi Mark,
For reproducing, if you're making the requests locally to the server that
might be why you're not seeing the issue occur. I had been testing between
servers (client on server A, tomcat on server B); I tried this morning
doing a wget locally to tomcat and do not see the issue occur (no
WSAECONNABORTED status) while doing the wget remotely does get the aborted
status.
in sslnetwork.c:ssl_socket_recv adding the following debug statements;
if (s == 0 && (SSL_get_shutdown(con->ssl) & SSL_RECEIVED_SHUTDOWN)) {
con->shutdown_type = SSL_SHUTDOWN_TYPE_STANDARD;
return APR_EOF;
}
printf("ssl_socket_recv:: Have value for i: %d\n", i);
printf("ssl_socket_recv:: Have value for s: %d\n", s);
printf("ssl_socket_recv:: Have value for rv: %d\n", rv);
printf("ssl_socket_recv:: con->shutdown_type: %d\n", con->shutdown_type);
fflush(stdout);
switch (i) {
case SSL_ERROR_WANT_READ:
case SSL_ERROR_WANT_WRITE:
Outputs:
Local server (wget --no-check-certificate https://localhost:8443/examples
)
ssl_socket_recv:: Have value for i: 5
ssl_socket_recv:: Have value for s: -1
ssl_socket_recv:: Have value for rv: 730054
ssl_socket_recv:: con->shutdown_type: 2
While on remote server performing the same request (wget
--no-check-certificate https://serverB:8443/examples)
ssl_socket_recv:: Have value for i: 5
ssl_socket_recv:: Have value for s: -1
ssl_socket_recv:: Have value for rv: 730053
ssl_socket_recv:: con->shutdown_type: 2
Thanks,
On Fri, Jan 6, 2017 at 5:43 PM, David Oswell <dosw...@gmail.com> wrote:
> Yep that would, Originally I had just turned the return 0 to throw an
> IOException - which as it would fall through to the else would be the same
> effect.
>
> I'll see if a java client would do the same, I'm using a golang
> client/console app for testing.
> I just tried with wget and see the WSAECONNABORTED status within APR.
> It also seems a bit time dependent, might be a case of whether APR is
> getting to the socket read before or after the FIN packet coming though ??
>
>
>
> On Fri, Jan 6, 2017 at 5:11 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 06/01/2017 21:50, David Oswell wrote:
>> > I've somehow gotten the build for tcnative working here (more shocked I
>> > finally got openssl to build!)
>> >
>> > There seems to be a slight difference in how the shutdown occurs. When
>> the
>> > APR_EGENERAL is returned its due to falling through the
>> SSL_ERROR_SYSCALL
>> > block in sslnetwork.c:ssl_socket_recv,
>> > This seems to be due to a difference in the value returned by;
>> > sslnetwork.c:324 : rv =
>> > apr_get_netos_error();
>> >
>> > on the bad case (quick socket close), rv is (730053) which
>> > is WSAECONNABORTED - APR_STATUS_IS_ECONNABORTED
>> > on a good disconnect case (slower socket close) rv is (730054)
>> > = WSAECONNRESET - APR_STATUS_IS_ECONNRESET
>> >
>> > I suspect a check with APR_STATUS_IS_ECONNABORTED(rv) might be needed to
>> > capture this scenario (WSAECONNABORTED), however I'm not sure how else
>> this
>> > status might occur, and if any of those cases should not flag it as
>> closed
>> > - although reading on WSAECONNABORTED it sounds like this is a close
>> case.
>> > Not sure if it's an exception case or just normal EOF though.
>>
>> Thanks. That is really useful information.
>>
>> I've been trying to re-create the original issue that led to this odd
>> 'treat an error as eagain' code but without success. I have found a
>> couple of other bugs (now fixed) so it wasn't a complete waste of time.
>>
>> When I added this hack I was fairly sure I was missing something and it
>> is looking increasingly like this code was fixing a symptom rather than
>> the root cause. Given that I can't re-create the original problem, I'm
>> leaning towards removing the special handling for EGENERAL and letting
>> it trigger a close.
>>
>> If you remove the
>> else if (-result == Status.APR_EGENERAL && isSecure()) {
>> ...
>> }
>>
>> block, does that fix the problem you are seeing?
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
