<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I've been playing around with it, and it looks like the interim problem of 1xx requests can be resolved if sendResponseHeaders is modified so that the sentHeaders is not set to true for 1xx status codes.<input name="virtru-metadata" type="hidden" value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","expirationDate":"2025-09-05T04:04:50.061Z","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"4","compose-window":{"secure":false}}"></div><div dir="ltr"><br></div><div dir="ltr"><div>The fix would be:</div><div><ul><li style="margin-left:15px">Check for 1xx status code</li><li style="margin-left:15px">If so, do not close the streams</li><li style="margin-left:15px">flush (but don't close) the raw outputstream </li><li style="margin-left:15px">set sentHeaders to false</li></ul></div></div><div>With this, I was able to call sendResponseHeaders again with the full response code and have it work. Thoughts? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>- will the server keep a reference to the connection/socket</div></blockquote><div dir="ltr"><br></div><div>Digging deeper into the code, the server already keeps a reference of every active connection, which is why the stop methods worked as normal. The Dispatcher thread also handles terminating the connection when the stream is closed manually.</div><div><br></div><div>Can you think of any other potential issues/scenarios with keeping the streams available for 1xx codes?</div><div></div><div><br></div><div>Thanks for your time,</div><div><br></div><div>-- Josiah</div>
</div>
</div>
</div>
</div>