[PATCH] Added $http2_stream_id

[J Carter]

Hello, 

On Mon, 22 May 2023 00:40:08 +0300
Maxim Dounin <mdounin at 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.carter at outlook.com> wrote:
> > 
> > > Hello,
> > > 
> > > On Sun, 14 May 2023 17:40:43 +0300
> > > Maxim Dounin <mdounin at mdounin.ru> wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Fri, May 12, 2023 at 03:37:52AM +0100, J Carter wrote:
> > > > 
> > > > > # HG changeset patch
> > > > > # User jordanc.carter at 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.