Errors and client side
- Problem the first:
- the store entry is no longer authoritative on the reply status. EBITTEST (E_ABORT) is no longer a valid test outside of client_side_reply.c. Problem the second: resources are wasted if we delay in cleaning up. Problem the third we can't depend on a connection close to clean up.
- Nice thing the first:
- Any step in the stream can callback with data representing an error. Nice thing the second: once you stop requesting reads from upstream, upstream can be stopped too.
- Solution #1:
- Error has a callback mechanism to hand over a membuf with the error content. The failing node pushes that back as the reply. Can this be generalised to reduce duplicate efforts? A: Possibly. For now, only one location uses this. How to deal with pre-stream errors? Tell client_side_reply that we want an error page before any stream calls occur. Then we simply read as normal.
Persistent connection logic:
- requests (httpClientRequest structs) get added to the connection list, with the current one being chr
- The request is immediately kicked off, and data flows through to clientSocketRecipient.
- If the data that arrives at clientSocketRecipient is not for the current request, clientSocketRecipient simply returns, without requesting more data, or sending it.
- ConnStateData::kick() will then detect the presence of data in the next ClientHttpRequest, and will send it, restablishing the data flow.
Web Site Translations