Passing null to parameter #1 ($haystack) of type string is deprecated

attaching patch for review.

The last submitted patch, 3: core-3344629-check-values-before-using-strpos-3.patch, failed testing. View results →

attached patch #5 while follow up on #3 failed in test.

The last submitted patch, 5: core-3344629-check-values-before-using-strpos-5.patch, failed testing. View results →

added updated patch and try to fix CCF of MR #14

Think it would worth figuring out what is calling with the empty parameter vs putting the check in. This could be bad code somewhere that should be fixed.

Either way will need a test case.

@smustgrave null is coming from public function get when headers[0] == NULL which is in vendor folder vendor/symfony/http-foundation/HeaderBag.php online 118 how we can change it ad it's not in code base ?

I think smustgrave is right. We need to know why there is a response that is built without any headers. That is pretty weird.

We really need to be able to reproduce this in a way, preferably in a test.

We're seeing this on image generation when adding a webp convert effect to an image style. Agree that there might be an underlying bug about not sending a proper content type in that case, but this seems like something we should just be more defensive about without requiring tests.

I think a simpler fix would be to use $response->headers->get('Content-Type') ?? '' if we can't rely on the default value behaviour in symfony.

> We're seeing this on image generation when adding a webp convert effect to an image style

In our case this was a bug in update function, so having this notice helped identifying that there is a problem in the first place.

For some reasons, this patch is already in Drupal 10.1.x
I upgraded a website using this patch from D9 to D10.1 and the patch was obviously failing.

If issue is no longer a problem in D10.1 we can close out!

Still, the issue exists in D10.1.5

I rerolled patch #19 to work with d10.1.5

I ran into a very similar issue.

\Drupal\jsonapi\Eventsubscriber\ResourceResponseValidator line 104

str_contains(): Passing null to parameter #1 ($haystack) of type string is deprecated

$response->headers->all() =

[
  'cache-control' => ['no-cache, private'],
  'date' => ['bla bla'],
  'content-type' => [null],
  'x-drupal-dynamic-cache' => ['UNCACHEABLE'],
];

Patch #5 took care of three occurrences

1. ActiveLinkResponseFilter
2. RssResponseRelativeUrlFilter
3. ResourceResponseValidator

Patch #29 for an unknown reason do nothing with ResourceResponseValidator.

In our case, we were seeing the 3 deprecation messages when an anonymous user tried to access a Data Export display of a View that required authentication.

The patch in #32 fixes the issue.