# HG changeset patch
# User Roman Arutyunyan
# Date 1643187691 -10800
# Wed Jan 26 12:01:31 2022 +0300
# Branch quic
# Node ID 9f5c59800a9894aad00b06df93ec454aab97372d
# Parent d3c6dea9454c48ded14b8c087dffc4dea46f78ef
QUIC: stream event setting function.
The function ngx_quic_set_event()
# HG changeset patch
# User Roman Arutyunyan
# Date 1643611590 -10800
# Mon Jan 31 09:46:30 2022 +0300
# Branch quic
# Node ID d3c6dea9454c48ded14b8c087dffc4dea46f78ef
# Parent 8dcb9908989401d750b14fe5dccf444a5485c23d
HTTP/3: proper uni stream closure detection.
Previously, closure
# HG changeset patch
# User Roman Arutyunyan
# Date 1643611562 -10800
# Mon Jan 31 09:46:02 2022 +0300
# Branch quic
# Node ID 8dcb9908989401d750b14fe5dccf444a5485c23d
# Parent 81a3429db8b00ec9fc476d3687d1cd18088f3365
QUIC: introduced explicit stream states.
This allows to eliminate the
- fixed flow control
- fixed stream closure
- added HTTP/3 uni stream closure patch
___
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org
On Fri, Jan 28, 2022 at 02:09:31PM +, Gao,Yan(媒体云) wrote:
> > c->quic is never set on main connection (it is not really needed there).
> > ngx_http_v3_init() is first called with main connection, and later it is
> > called with _another_ connection that is a stream, and it has c->quic set.
>
>
Thanks for reviewing.
We've reconsidered that. After all, a new patch has been pushed below this.
> the following set of headers will result in caching being incorrectly
enabled (while it should be disabled due to Set-Cookie header):
Sorry, we had lost these points. So we reconsidered that it
Hi!
Thanks for sharing patches. It's interesting for me and I'm going to test
it soon.
For this particular patch I would suggest to reduce the scope of mutex
locking
and remove it when "serve_tempfile" is not configured. See my version below:
diff --git a/src/http/ngx_http_file_cache.c
Hello!
On Sat, Jan 29, 2022 at 01:50:24PM +, CHHABRA Mandeep Singh via nginx-devel
wrote:
> > Sure, intermediate certificates are not required to be known
> > by the server and can be provided by the client in the extra
> > certificates during SSL/TLS handshake.
>
> I am not sure what