Multiresponse normalizer invalid headers "sub-content-type" [#3096577]

While using subrequests I consistently retrieve following notice "Notice: Undefined index: sub-content-type" which flushes the database.

It seems on the MultiresponseJsonNormalizer the sub-content-type is included in the headers but this is never set.

/**
 * Normalizes multiple response objects into a single string.
 */
class MultiresponseJsonNormalizer implements NormalizerInterface {

  /**
   * {@inheritdoc}
   */
  public function normalize($object, $format = NULL, array $context = []) {
    // Prepare the root content type header.
    $content_type = sprintf(
      'application/json; type=%s',
      $context['sub-content-type'],
    );
    $headers = ['Content-Type' => $content_type];

    ...

When checking existence before including this seems to be fixed. Should this be included in the first place and any idea's on why this is empty?

Comment	File	Size	Author
#3	multiresponse_normalizer_invalid_headers_sub_content_type-3096577-3.patch	575 bytes	vensires

Issue fork subrequests-3096577

Show commands

Start within a Git clone of the project using the version control instructions.

Add & fetch this issue fork’s repository

Or, if you do not have SSH keys set up on git.drupalcode.org:

Add & fetch this issue fork’s repository

3096577-multiresponse-normalizer-invalid compare
Check out this branch for the first time

Check out existing branch, if you already have it locally

About issue forks

Comments

Comment #1

25 November 2019 at 10:28

smanhoff created an issue. See original summary.

Comment #2

vensires

Greece

commented 15 April 2020 at 10:37

Priority:

Major

» Normal

In my case I, have a view with a REST display enabled using the default cookie provided and having chosen as required format the json. If the subrequests module is disabled and I try to visit a view's page without any results (eg. ?page=1000), a 200 JSON Response with no body but a proper header Content-type: application/json gets returned.

If I enable the subrequests module and visit the same page again, I get the following body instead of an empty one: {"content":"[]","headers":{"Content-Type":"application\/json; type="}}.

I also add the backtrace for my scenario:

Notice: Undefined index: sub-content-type in Drupal\subrequests\Normalizer\MultiresponseJsonNormalizer->normalize() (line 21 of modules/contrib/subrequests/src/Normalizer/MultiresponseJsonNormalizer.php).
Drupal\subrequests\Normalizer\MultiresponseJsonNormalizer->normalize(Array, 'json', Array) (Line: 143)
Symfony\Component\Serializer\Serializer->normalize(Array, 'json', Array) (Line: 116)
Symfony\Component\Serializer\Serializer->serialize(Array, 'json', Array) (Line: 142)
Drupal\rest\Plugin\views\style\Serializer->render() (Line: 450)
Drupal\rest\Plugin\views\display\RestExport->Drupal\rest\Plugin\views\display\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 451)
Drupal\rest\Plugin\views\display\RestExport->render() (Line: 1533)
Drupal\views\ViewExecutable->render() (Line: 441)
Drupal\rest\Plugin\views\display\RestExport->execute() (Line: 1630)
Drupal\views\ViewExecutable->executeDisplay('list', Array) (Line: 78)
Drupal\views\Element\View::preRenderViewElement(Array)

I don't know if that's your case @smanhoff but this bug really is something annoying and without good reason I believe. I still consider it a Major bug which the isset() you suggest doesn't fix since it also adds body where it shouldn't and of a different type (eg. views originally returns array, subrequests returns object).

Comment #3

vensires

Greece

commented 15 April 2020 at 12:21

Priority:	Normal	» Major
Status:	Active	» Needs review

Status	File	Size
new	multiresponse_normalizer_invalid_headers_sub_content_type-3096577-3.patch	575 bytes

Setting this back to Major since I accidentally dropped it. I also attach a patch which fixes the issue for me.

\Symfony\Component\Serializer\Serializer::getNormalizer() passes the $context parameter to each normalizer's supportsNormalization method even if \Symfony\Component\Serializer\Normalizer\NormalizerInterface doesn't mention it. To avoid breaking anything, I get this $context and validate it using func_get_arg() instead of expecting it in the method's parameters.