Hello! On Sun, May 14, 2023 at 11:59:35PM +0100, J Carter wrote:
> Hello, > > >On Sun, 14 May 2023 18:48:06 +0100 > >J Carter <jordanc.car...@outlook.com> wrote: > > > Hello, > > > > On Sun, 14 May 2023 17:40:43 +0300 > > Maxim Dounin <mdou...@mdounin.ru> wrote: > > > > > Hello! > > > > > > On Fri, May 12, 2023 at 03:37:52AM +0100, J Carter wrote: > > > > > > > # HG changeset patch > > > > # User jordanc.car...@outlook.com > > > > # Date 1683858766 -3600 > > > > # Fri May 12 03:32:46 2023 +0100 > > > > # Node ID de1a1b4141e827984cbd0d2feb97f870c32ff289 > > > > # Parent b71e69247483631bd8fc79a47cc32b762625b1fb > > > > Added $http2_stream_id > > > > > > > > Useful for tracing multiplexed requests from client logs or pcaps > > > > captured between client and nginx, to nginx's own access logs. > > > > > > > > Also useful for matching multiplexed request's access log entries > > > > to debug level error logs - which is particularly difficult to do. > > > > > > Thanks for the patch, but I would rather not. > > > > > > Consider using $connection_requests variable to identify > > > individual requests within a connection, > > > or the $request_id > > > variable to identify requests globally. These do no depend on the > > > particular protocol used and can be universally used for both > > > HTTP/1.x and HTTP/2. > > > > > > > Thanks for the reply. > > > > I hadn't considered $connection_requests. Yes that would work fine > > for my use-case with some log processing ($connection_requests * 2 - > > 1) > > > > One thought does come to mind, although it won't effect my use-case - > > This may not work if server push is used as that would increment > > stream id, but presumably would not increment connection->requests > > (I'd need to check that though). > > After some additional testing with $connection_requests it appears > to not be suitable method of obtaining stream id in access_logs. > > The issue is > 1) Stream id and connection->requests are incremented on stream > / request initiation. > 2) Access logs are written on request finalization. > 3) New streams may be initiated at any time. > 3) Requests are not necessarily finalized in initiation order. > > Therefore making any assumptions as to the stream id associated with a > request from to the current value of connection->requests at > finalization time is impossible. In HTTP/2, for each stream nginx creates a new connection, and r->connection->requests as seen by $connection_requests will be frozen for the request lifetime. That is, it essentially shows the request sequence number. > I'd ask that this patch is reconsidered. While $connection_requests is certainly not exactly equivalent to HTTP/2 stream id, the $connection_requests is believed to be enough for user-level tasks, as well as for most debugging tasks. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel
