[PATCH] Added $http2_stream_id

[J Carter]

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.

I'd ask that this patch is reconsidered.