Skip to content

fix(common): strip XSSI prefix for all JSON responses#19917

Closed
Linskeyd wants to merge 1 commit intoangular:masterfrom
Linskeyd:fix-xssi-prefix
Closed

fix(common): strip XSSI prefix for all JSON responses#19917
Linskeyd wants to merge 1 commit intoangular:masterfrom
Linskeyd:fix-xssi-prefix

Conversation

@Linskeyd
Copy link
Copy Markdown
Contributor

@Linskeyd Linskeyd commented Oct 25, 2017

This fixes a regression where the common XSSI prefix
used to be stripped for all json responses, including
error responses.

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] angular.io application / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Submitting in response to comment on #19773
Tagging @alxhub

What is the new behavior?

The common XSSI prefix will now be stripped, even in the error response scenario.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

This fixes a regression where the common XSSI prefix
used to be stripped for all json responses, including
error responses.
body = { error, text: body } as HttpJsonParseError;
} else {
// Cannot be certain that the body was meant to be parsed as JSON.
// Leave the body as a string.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it is worth preserving the XSSI_PREFIX in this case. (I think it is.)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the event that the XSSI prefix is present, it must be removed prior to even attempting the parse (or the parse would fail). Are you suggesting that if the parse fails (after removal of the prefix, assuming it is there) that the prefix should be re-added to the body? Why would we want to preserve the prefix when we already already confirmed above that the req.responseType is 'json'?

The scenario in which this would occur would have to be malformed json that exists after the prefix is already removed. I don't see a good reason to preserve the prefix in this case.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if the requests responseType is json, there is no guarantee that the returned response will be in JSON format in case of an error (which is what this branch is for).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, XSSI should be here, I just approached this issue on our app.

@IgorMinar IgorMinar requested a review from alxhub October 25, 2017 23:49
@IgorMinar IgorMinar added area: common/http Issues related to HTTP and HTTP Client action: review The PR is still awaiting reviews from at least one requested reviewer labels Oct 25, 2017
@Linskeyd
Copy link
Copy Markdown
Contributor Author

@alxhub when you get a chance to review this, it looks like the lint is failing for a commit message unrelated to mine.

@gkalpak
Copy link
Copy Markdown
Member

gkalpak commented Oct 31, 2017

BTW, there is overlap between this PR and #19958.

@Linskeyd
Copy link
Copy Markdown
Contributor Author

Seems like the other PR (#19958) addresses this issue with additional changes on top of the ones I've made above. Happy to close this in favor of that PR - just want to see the issue fixed.

@Linskeyd Linskeyd closed this Oct 31, 2017
@alxhub
Copy link
Copy Markdown
Member

alxhub commented Oct 31, 2017

@Linskeyd indeed, I've factored this change into the other. Thank you for the PR, I based my commit off of this change.

@angular-automatic-lock-bot
Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: review The PR is still awaiting reviews from at least one requested reviewer area: common/http Issues related to HTTP and HTTP Client cla: yes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants