[PATCH] Added $http2_stream_id

[Maxim Dounin]

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'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/