Error is 10053 but StatusCode is 200

[HTMLValidator.com 5]

In the RequestDone event of a TSslHttpCli object, a user is reporting that he's getting Error 10053 but StatusCode is 200 and ReasonPhrase is "OK".

 

This seems to only happen on his "test" server and not his "production" server. The "test" server has a lot less resources and it's being hit hard with a lot of requests but I'm not sure that explains what's happening.

 

Why would Error be 10053 but StatusCode and ReasonPhrase indicate no error?

 

UPDATE: Customer adds: "The test and production servers have same configuration files (Apache + nginx), same settings for SSL/TLS (ciphers...). The difference is that the test server uses self-generated certificate, while the production server has certificate issued by Certificate Authority. Most (if not all browsers) do not like self-generated certificate (or bad or obsolete certificates) and issue warning with such URLs. The problem is that only some links (5000+) got 10053 error, not all (300K+ if I remember well) if I refer to the statistics shown during run, so probably the server load would be part of the problem, not the protocol itself."

 

Thank you!

Edited December 23, 2020 by HTMLValidator.com

[FPiette 363]

55 minutes ago, HTMLValidator.com said:

Error 10053

WSAECONNABORTED 10053

Software caused connection abort. An established connection was aborted by the software in your host computer, possibly due to a data transmission time-out or protocol error.

[HTMLValidator.com 5]

3 hours ago, FPiette said:

WSAECONNABORTED 10053

Software caused connection abort. An established connection was aborted by the software in your host computer, possibly due to a data transmission time-out or protocol error.

Thanks... but if the connection was aborted, why a StatusCode of 200 and ReasonPhrase of "OK"? Perhaps the connection was aborted after the status was received?

Interesting:

https://www.chilkatsoft.com/p/p_299.asp

Edited December 24, 2020 by HTMLValidator.com

[Fr0sT.Brutal 897]

Server has sent a response and broke the connection forcibly. I wouldn't bother as long as response being sent is complete

[Angus Robertson 519]

HTTP/1.1 keeps the connection open to handle repeated requests, so one request may work, then seconds later the connection is closed and you get an error without another request starting.  How this is reported is down to the developer.

 

Angus

 

[HTMLValidator.com 5]

Thank you all. This is regarding a link checker in my software... so if the Error is 10053 and StatusCode is 200 then I'll just assume the link exists and ignore the 10053 error.

[Remy Lebeau 1256]

10 hours ago, Angus Robertson said:

HTTP/1.1 keeps the connection open to handle repeated requests

By default, but that is not a requirement.  You have to look at the response's Connection header to know for sure whether the server is leaving the connection open or not.

10 hours ago, Angus Robertson said:

so one request may work, then seconds later the connection is closed

If the connection is closed by the server, the response's Connection header will be set to "close", and the socket connection should be gracefully closed (but that depends on implementation) immediately after the last byte of the response has been sent.

10 hours ago, Angus Robertson said:

and you get an error without another request starting.

This kind of socket error can only happen if the client tries to read more bytes after the connection has been lost.  Which means either the client is not detecting the end of the response correctly so it knows when to stop reading, or the server is not reporting the end of the response correctly.  If the response's Content-Length header is missing, EOF is reported by socket connection closure (unless the response's Content-Type is a self-terminating media type, like MIME), so the server SHOULD close the connection gracefully, not abortively.  If the Content-Length is present but has an invalid value, then the client may try to read more bytes than is actually being sent, which may lead to an abortive closure.