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