What triggers a SlowResponsiveClient error in HTTPERR log?

[charlesc32]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

In the browser the request shows a 200 response but gets a net::ERR_CONNECTION_RESET error.

In the ASP.NET Core logs we see the request finishing with a 200
Request finished HTTP/2 GET - - - 200 - application/json;+charset=utf-8 17292.3150ms|

In the IIS logs I see that the request is logged with a 500.19 error:
2023-12-12 21:06:16 10.18.114.208 GET 6500 - 10.18.114.6 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/120.0.0.0+Safari/537.36 500 19 64 17292

In the HTTPERR log I see a SlowResponsiveClient error code. I cannot find any documentation on what this error means or if it can be configured with any settings:
2023-12-12 21:06:16 10.18.114.6 5921 10.18.114.208 6500 - - - - - - SlowResponsiveClient -

Describe the solution you'd like

Provide documentation on what the SlowResponsiveClient error means and any means of configuring HTTP.SYS to control this response.

Additional context

No response

[amcasey]

I'm not specifically familiar with that error code, but the first thing that comes to mind is that it's normal for servers to set a minimum response read rate to guard against slow read attacks. This is more likely to affect large responses. Does that seem at all relevant to your scenario?

[amcasey]

Again, I'm not specifically familiar with this code, but it looks like it's reported when CurrentBytesPending exceeds IdealBytesPending where, presumably, the bytes in question are from the response.

[amcasey]

@charlesc32 Any chance you can provide server logs?

netsh trace start scenario=InternetServer_dbg cap=yes rep=di pers=no cor=di perf=no
<repro>
netsh trace stop

[charlesc32]

I'm not specifically familiar with that error code, but the first thing that comes to mind is that it's normal for servers to set a minimum response read rate to guard against slow read attacks. This is more likely to affect large responses. Does that seem at all relevant to your scenario?

My hunch is the same but there is a specific setting and error for that (minBytesPerSecond) so SlowResponsiveClient must be something slightly different.

Again, I'm not specifically familiar with this code, but it looks like it's reported when CurrentBytesPending exceeds IdealBytesPending where, presumably, the bytes in question are from the response.

Thanks for this. Is there a way to control the tolerance between the two?

@charlesc32 Any chance you can provide server logs?

netsh trace start scenario=InternetServer_dbg cap=yes rep=di pers=no cor=di perf=no
<repro>
netsh trace stop

I will look in to this.

[charlesc32]

@charlesc32 Any chance you can provide server logs?

netsh trace start scenario=InternetServer_dbg cap=yes rep=di pers=no cor=di perf=no
<repro>
netsh trace stop

@amcasey
Ok I have this trace. It is 250mb big though. What exactly should I be looking for?

[charlesc32]

I have several of these in the trace

Event Name Time MSec Process Name Rest

Microsoft-Windows-HttpService/HTTPRequestTraceTask/SndError 37,425.067 Process(4) (4) ThreadID="5,604" ProcessorNumber="1" RequestId="-720,575,933,936,804,410" Reason="SendResponseFailed" Status="-1,073,741,536" FormattedMessage="Error -1,073,741,536 occurred while sending (corresponding to request ID -720,575,933,936,804,410). A TCP Reset will be sent. " ActivityID="80005dc6-0001-f600-b63f-84710c7967bb"

[amcasey]

Sorry, it's the time of year when all the experts go on vacation. 🎄

I can tell you that that HRESULT indicates cancellation, but that's probably just a side effect of the SlowResponsiveClient.

Did you ever look into the 500.19? That does have docs, though they may just indicate that it's downstream from the httpsys issue.

[charlesc32]

No worries, thanks for your help so far.

500.19 usually indicates an issue with the web.config so I think that's probably a red herring.

I did find this blog post about a similar issue with a 500.19 being logged for a client cancellation by the dynamic compression module:

https://techcommunity.microsoft.com/t5/iis-support-blog/iis-logs-500-19-if-a-client-drops-connection-while-loading-the/ba-p/364572

[macoxms]

To decode the etl fully, internal pdbs/tmfs are required, so we will need your etl to investigate.

Without the trace, all I can say is that the SlowResponsiveClient indicates that a significant set of non-flow-controlled bytes were sent and not ACK’d in a timely fashion by the peer.

This could be caused by the client forcing the server to send a large amount of non-flow-controlled data, or the client not draining the data.

Your IIS link indicates that 500.19 is a generic failure code for the dynamic compression module which probably happened because of the SlowResponsiveClient failure in http.sys.