Allow passing `HttpRequest` to `XhrFactory.build()` for request-aware XHR customization

[abdulkareemnalband]

Which @angular/* package(s) are relevant/related to the feature request?

common

Description

HttpClient uses XhrFactory.build() to create XMLHttpRequest instances.

Currently, build() does not receive the associated HttpRequest, so a custom XhrFactory cannot access request-specific data.

In our case, metadata is added to the request using HttpContext. We want to read that metadata in a custom XhrFactory and attach it to the created XMLHttpRequest. Existing tracing/instrumentation code can then pick up the metadata from the XHR object.

Without access to the HttpRequest, there is no clean way to connect HttpContext metadata with the created XHR instance.

Proposed solution

Allow XhrFactory.build() to optionally receive the HttpRequest.

Example:

abstract class XhrFactory {
  abstract build(req: HttpRequest<unknown>): XMLHttpRequest;
}

Angular’s internal usage could pass the request when creating the XHR:

const xhr = this.xhrFactory.build(req);

A custom implementation could then read metadata from HttpContext and attach it to the XHR:

@Injectable()
export class CustomXhrFactory implements XhrFactory {
  build(req: HttpRequest<unknown>): XMLHttpRequest {
    const xhr = new XMLHttpRequest();

    const metadata = req.context.get(MY_METADATA_CONTEXT_TOKEN);

    if (metadata) {
      (xhr as any).__metadata = metadata;
    }

    return xhr;
  }
}

The parameter should be optional so existing XhrFactory implementations continue to work.

Alternatives considered

HTTP interceptors

Interceptors can access HttpRequest and HttpContext, but they cannot access the underlying XMLHttpRequest. So they cannot attach the metadata to the XHR object.

Shared/global state

Metadata could be stored globally before the XHR is created and then read inside XhrFactory.build().

This is fragile, especially with concurrent requests, and adds hidden coupling.

Using headers

Headers can carry metadata over the network, but they do not help with attaching metadata to the in-memory XHR object that existing tracing/instrumentation code reads.

[SkyZeroZx]

I understand you want to share global metadata across all states in an XhrFactory object, but what would be the point of doing this there instead of in a service?

Because currently, the HttpClient exposes (if I'm not mistaken) all the XMLHttpRequest options.

Are you referring to having metadata to track requests (similar to Sentrylog, Google Tag, etc.)?

[abdulkareemnalband]

We have a custom telemetry code which reads data from non standard properties as shown in example, to attach further metadata to telemetry. I am thinking to use HttpContext to store that data and attach that when XMLHttpRequest object is created.

Also metadata is not global, it is related to current request

[SkyZeroZx]

I'm not a telemetry expert, but in my opinion, this isn't good practice or desirable because we'd be mutating objects (which I understand is what we want to do: dynamically modify an xhr instance to add a property).

I think you could do something similar with an interceptor and send it in a header (and in my experience, the most viable option would be an x-trace-id).

[alan-agius4]

As mentioned by @SkyZeroZx in general for tracing, headers should be used and mutating the XHR object to store metadata creates a dependency on a specific implementation that doesn't translate to other transport methods.

If the goal is to trace requests, we should be using standard HTTP headers. This ensures the tracing logic works across both XHR and fetch, and allows the metadata to be properly propagated through to the backend. Using headers keeps the application logic separated from the underlying network object.