Hello, On Mon, 22 May 2023 00:40:08 +0300 Maxim Dounin <mdou...@mdounin.ru> wrote:
> 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 see.. I must've messed my tests of this up somehow - this explanation makes sense though. > > > 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. > Yes agreed considering the above, I can indeed just offset the value. Thanks again. _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel
