feat: handle */* accept header

[lag-of-death]

Fixes #492

Checklist

• Tests have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

Bug fix.

Does this PR introduce a breaking change?

No.

[philsturgeon]

This TODO was asking a good question, why are we trying to ensure utf-8 is specified in there? Stuff might not be, what if the content type is application/xml; charset=iso-8859-1, would this make it: application/xml; charset=iso-8859-1; charset=utf-8?

@XVincentX do you know what the original intent was here?

[lag-of-death]

could be something to consider for another PR 👍

[philsturgeon]

Sadly it is directly related to this code because you are adding this functionality in this PR and I am not sure we should be adding this functionality.

[lag-of-death]

@philsturgeon, I'm not adding anything big really. I just fixed some discrepancies. In most of the tests, json responses had charset=utf-8, so I added that to the responses that didn't have it.

[philsturgeon]

This code is forcing '; charset=utf-8') onto all responses even when nothing anywhere in the OpenAPI document or anywhere in the HTTP request or anywhere has suggested that we should. Could you explain your reasoning for adding this? Unless there is a compelling reason to add this (which I cannot think of¡) then we should not be adding this.

[lag-of-death]

@philsturgeon, so, it was Fastify that was adding the charset. All of the responses to requests that asked for application/json were serialized with the default Fastify serializer. This serializer was adding this encoding. In the cases of the adjusted tests files, ; charset=utf-8 was missing. Why? Because of -H "accept: application/xml, application/json". So Fastify sees this and decides to serialize the response with

prism/packages/http-server/src/serializers.ts

Line 29 in a71e853

return !!typeIs.is(value, ['application/xml', 'application/*+xml']);

, hence no ; charset=utf-8 (because it no longer used the default serializer). And why did this even work? Because of

prism/packages/http-server/src/serializers.ts

Line 31 in a71e853

serialize: (data: unknown) => (typeof data === 'string' ? data : xmlSerializer.parse(data)),

. So.. we had a string from the test file, so the XML serializer was not really serializing it. And yet, we still got application/json in the content-type, because it was done by

prism/packages/http-server/src/server.ts

Line 89 in 264d8b2

const response = await prismInstance.process(input, operations);

cc @XVincentX

basically, my work was done with consistency in mind, but I'm happy to not force that encoding for application/json. Will need to adjust the tests though :)

[XVincentX]

I do not think all this reorganisation is required. All we need to do is to add a hook before sending the payload and if we detect that the accept is */*, handle the payload differently.

Something among these lines should work and keep the current structure as it is.

  server.addHook('onSend', (request, reply, payload, done) => {
    if (request.headers.accept === '*/*') {
      const s = reply.hasHeader('content-type')
        ? serializers.find(s => s.regex.test(reply.getHeader('content-type')!))
        : serializers[0];
      if (s) {
        return done(undefined, s.serializer(payload));
      }
      return done(undefined, payload);
    }
  });

[XVincentX]

I've put a simplified and less invasive solution in #578.

[XVincentX]

Superseded by #578