Hello,

On Mon, 22 May 2023 00:40:08 +0300
Maxim Dounin <mdounin@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@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 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