Re: https://bugs.chromium.org/p/boringssl/issues/detail?id=558#c1
Since a recent change that puts boringssl's public API more in line with OpenSSL, there is a constness mismatch in the function type of `copy_X509` that may cause compilation failures.
As it turns out, the function we are using there (`sk_deep_copy`) is documented as a private API. We could use `sk_X509_deep_copy`, casting away the const in `copy_X509` to increment the refcount, but the existing function `X509_chain_up_ref` does exactly what we want here.
1) on_new_conn only be called after handshake_ok
2) on_conn_closed only be called by ietf_full_conn_ci_destroy
Co-authored-by: wangfuyu <ivanfywang@gmail.com>
* fix memory leak when gquic50 decrypt packet
fix a suspicious memory leak in gquic and iquic
* drop some redundant checking.
Co-authored-by: linsc <linsc@wangus.com>
RFC9000 3.5.
A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the "Ready" or "Send" state. If the stream is in the "Data Sent" state, the endpoint MAY defer sending the RESET_STREAM frame until the packets containing outstanding data are acknowledged or declared lost. If any outstanding data is declared lost, the endpoint SHOULD send a RESET_STREAM frame instead of retransmitting the data.
RFC9000 19.4. RESET_Frames
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly terminate the sending part of a stream.
Co-authored-by: wangfuyu <wangfuyu@gmail.com>
