Skip to content

Intercept resets compatible content type when body is an object #17084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Lakitna opened this issue Jun 23, 2021 · 6 comments · Fixed by #17199 or #17401
Closed

Intercept resets compatible content type when body is an object #17084

Lakitna opened this issue Jun 23, 2021 · 6 comments · Fixed by #17199 or #17401

Comments

@Lakitna
Copy link
Contributor

Lakitna commented Jun 23, 2021

Current behavior

The following test passes:

const axios = require('axios');

it('overwrites the content-type header', () => {
    cy.intercept('http://localhost:3000', (req) => {
        req.on('response', (res) => {
            res.send({
                statusCode: 500,
                headers: {
                    // A variant of the normal json content type specifically designed
                    // for error messages.
                    'content-type': 'application/problem+json',
                    'access-control-allow-origin': '*',
                },
                body: {
                    status: 500,
                    title: 'Internal Server Error',
                },
            });
        });
    });

    axios
        .get('http://localhost:3000')
        .catch((error) => {
            // Note that this asserts the standard json content type
            expect(error.response.headers['content-type']).to.equal('application/json');
        });
});

image

Desired behavior

.intercept() should not overwrite the content type if I explicitly provide one. Especially if my content type matches the response body.

Or, in other words. The following test should pass:

The test
const axios = require('axios');

it('does not overwrite the content-type header', () => {
  cy.intercept('http://localhost:3000', (req) => {
      req.on('response', (res) => {
          res.send({
              statusCode: 500,
              headers: {
                  'content-type': 'application/problem+json',
                  'access-control-allow-origin': '*',
              },
              body: {
                  status: 500,
                  title: 'Internal Server Error',
              },
          });
      });
  });

  axios
      .get('http://localhost:3000')
      .catch((error) => {
          // Now asserts the content type for Problem JSON
          expect(error.response.headers['content-type']).to.equal('application/problem+json');
      });
});

Test code to reproduce

As above :)

I also have a random server up at http://localhost:3000. Since we're replacing the response of the server anyway, it really doesn't matter what's running there. My server is an Express Hello World :)

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
    res.send('Hello World!')
})

app.listen(port, () => {
    console.log(`Example app listening at http://localhost:${port}`)
})

Versions

Cypress: 7.5.0

Workaround

I already found a workaround. I'll share it in case it helps someone else.

This only happens when your response body is an object, so all you have to do is stringify it like so:

const axios = require('axios');

it('overwrites the content-type header', () => {
    cy.intercept('http://localhost:3000', (req) => {
        req.on('response', (res) => {
            res.send({
                statusCode: 500,
                headers: {
                    'content-type': 'application/problem+json',
                    'access-control-allow-origin': '*',
                },
                // Stringify as a workaround. This issue only happens when body is an
                // object. `JSON.stringify` turns it into a string instead.
                body: JSON.stringify({
                    status: 500,
                    title: 'Internal Server Error',
                }),
            });
        });
    });

    axios
        .get('http://localhost:3000')
        .catch((error) => {
            expect(error.response.headers['content-type']).to.equal('application/problem+json');
        });
});
@sainthkh
Copy link
Contributor

sainthkh commented Jul 5, 2021

Sorry for the late reply.

I tested it by copying and pasting it. But found out that error.response is undefined. Is there something I am missing?

@sainthkh sainthkh added the stage: awaiting response Potential fix was proposed; awaiting response label Jul 5, 2021
@Lakitna
Copy link
Contributor Author

Lakitna commented Jul 5, 2021

Did you start the dummy server on localhost:3000?

Without the dummy server running I get this:

image

This sounds like what you're describing

@cypress-bot cypress-bot bot added stage: work in progress stage: needs review The PR code is done & tested, needs review and removed stage: awaiting response Potential fix was proposed; awaiting response stage: work in progress stage: needs review The PR code is done & tested, needs review labels Jul 6, 2021
@cypress-bot cypress-bot bot added stage: pending release and removed stage: needs review The PR code is done & tested, needs review labels Jul 12, 2021
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jul 12, 2021

The code for this is done in cypress-io/cypress#17199, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@flotwig
Copy link
Contributor

flotwig commented Jul 19, 2021

Reverted, see #17401

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Aug 6, 2021

The code for this is done in cypress-io/cypress#17401, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot cypress-bot bot added stage: pending release and removed stage: ready for work The issue is reproducible and in scope labels Aug 6, 2021
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Aug 16, 2021

Released in 8.3.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v8.3.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Aug 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants