I believe this test should be passing, but doesn't.

    it('should delete only the exact matching string value, not substrings', () => {
      const headers = new HttpHeaders({
        'X-Scopes': ['tenant:alpha', 'tenant:alpha:archive'],
      });

      // We only want to delete the 'tenant:alpha:archive' value
      const updated = headers.delete('X-Scopes', 'tenant:alpha:archive');

      expect(updated.getAll('X-Scopes')).toEqual(['tenant:alpha']);
    });

Potentially we should also have this one to pass:

it('should treat an empty string as a specific value to delete', () => {
  const headers = new HttpHeaders({ foo: ['', 'bar'] });
  // We only want to delete the empty string
  const updated = headers.delete('foo', '');

  // causing the entire 'foo' header key to be wiped out.
  expect(updated.getAll('foo')).toEqual(['bar']);
});

I believe this test should be passing, but doesn't.

    it('should delete only the exact matching string value, not substrings', () => {
      const headers = new HttpHeaders({
        'X-Scopes': ['tenant:alpha', 'tenant:alpha:archive'],
      });

      // We only want to delete the 'tenant:alpha:archive' value
      const updated = headers.delete('X-Scopes', 'tenant:alpha:archive');

      expect(updated.getAll('X-Scopes')).toEqual(['tenant:alpha']);
    });

Potentially we should also have this one to pass:

it('should treat an empty string as a specific value to delete', () => {
  const headers = new HttpHeaders({ foo: ['', 'bar'] });
  // We only want to delete the empty string
  const updated = headers.delete('foo', '');

  // causing the entire 'foo' header key to be wiped out.
  expect(updated.getAll('foo')).toEqual(['bar']);
});

These tests are actually here in this commit 7290fe9 (this commit) and they pass in local
Or do you mean something else?

Not sure why this was logged with GVP.

Since the immutability contract isn't respected during SSR, headers can be mutated unexpectedly, adding or removing scopes. One possible case is TransferCache excluding a sensitive header, but because the contract isn't honored, it isn't recognized and ends up in the final HTML.

I can't confidently assess the severity, but given this, I think it might at least be worth backporting ?

AGENT: I have re-reviewed this PR and found two issues regarding the implementation of the fix:

Issue 1: Inconsistent deletion behavior between HttpHeaders and HttpParams

The PR correctly refactors HttpHeaders to fix a substring matching bug when deleting values. By using filter(), it successfully removes all occurrences of the targeted value if it was added multiple times.
However, the deletion logic in HttpParams was not updated and still uses indexOf and splice(idx, 1). Because it only splices once, HttpParams will only remove the first occurrence of a matching value. This creates an inconsistent API behavior between the two classes (for reference, the standard URLSearchParams.delete(name, value) deletes all matching occurrences).

Issue 2: Eager O(N) memory allocation (Performance Regression)

To preserve immutability, the PR fixes the shared array mutation bug by eagerly slicing every single array in the map during init():

for (const [key, values] of other.headers.entries()) {
  this.headers.set(key, values.slice());
  // ...
}

This forces an O(N) copy of the entire header/parameter map into memory upon initialization, regardless of how many keys are actually being modified. A more performant copy-on-write approach would be to leave the arrays shared initially, and only invoke .slice() locally inside applyUpdate for the specific array that is actively being mutated (e.g., before base.push() or base.splice()).

This PR was merged into the repository. The changes were merged into the following branches:

• main: f33ee95
• 22.0.x: 2ed6a8e
• 22.1.x: 39e362e