Huma middleware can't access some information comming from the http.Request

[aureliar8]

I'm in the process of adding opentelemetry support to one of our project that uses huma.

As I want to set the operationID that was matched to this request as a span name/attribute I need to make that at the huma middleware. (An router-level middleware wouldn't have this information)

In this middleware I need to crate a new opentelemetry span and then attach some attribute to it that describe the request.
This list of attribute is standardized. There are two attributes that are required by the standard and that can't be accessed from a huma.Context (unless I missed something)

• Whether or not tls is used for the request
• The http version used for the request (1.0/1.1/2.0...)

In other opentelemetry interceptors & middleware this information is extracted from the http.Request struct and specifically the r.TLS, r.Proto, r.ProtoMajor and r.ProtoMinor fields.

[danielgtaylor]

@aureliar8 this seems like a missing feature in the adapter interface. I'll see if I can get it added to enable this use case. Thanks for reporting!

[george-rogers]

@danielgtaylor any reason why huma.Context cannot expose the underlying *http.Request? That would save some hassle and we wouldn't have to deal with manual wiring of the adapter

It would be nice to also allow overriding the underlying http.ResponseWriter as other observability APIs automatically instrument it, eg. NewRelic

[danielgtaylor]

@george-rogers not all routers use the standard library for HTTP, for example Fiber has its own HTTP library with its own request type, so we couldn't just return an *http.Request. I've been spending some time thinking about how to simplify this but am not sure what we can do yet.

[joa23]

@danielgtaylor - just exporting the ChiContext would be sufficient for my use case. e.g. type chiContext struct { -> type ChiContext struct { as I could just cast it in the middleware. No?