Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix: normalize SOAP carriage returns on import and UI rendering#1968

Open
Caesarsage wants to merge 1 commit intomicrocks:1.13.xfrom
Caesarsage:fix-1951
Open

fix: normalize SOAP carriage returns on import and UI rendering#1968
Caesarsage wants to merge 1 commit intomicrocks:1.13.xfrom
Caesarsage:fix-1951

Conversation

@Caesarsage
Copy link
Contributor

Description

  • Normalize \r\n / \r to \n during SoapUI import in SoapUIProjectImporter so persisted request/response payloads are clean.
  • Add regression test testCRLFPayloadsAreNormalizedOnImport with a CRLF fixture SoapUI project.
  • Add UI safety-net normalization in Service Detail display path using normalizeLineEndings from format-utils.

This prevents hidden carriage return anomalies in SOAP payload handling and display.

Related issue(s)

Fixes #1951

@Caesarsage
Copy link
Contributor Author

cc @SebastienDegodez @lbroudoux

@lbroudoux
Copy link
Member

cc @SebastienDegodez @lbroudoux

I have the week off and will be back Monday 2nd.

Copy link
Member

@lbroudoux lbroudoux left a comment

Choose a reason for hiding this comment

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

Is it possible to only handle this on client side to keep the imported artifact as the source of truth? I wouldn't expect changes on server side importer.

Comment on lines +731 to +732
response.setContent(
normalizeLineEndings(getConfigUniqueDirectChild(mockResponse, "responseContent").getTextContent()));
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer not to change the imported content as it has to be "the source of truth". Couldn't we manage this only on client side?

request.setName(testRequest.getAttribute(NAME_ATTRIBUTE));
if (hasConfigDirectChild(testRequest, REQUEST_TAG)) {
request.setContent(getConfigUniqueDirectChild(testRequest, REQUEST_TAG).getTextContent());
request
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer not to change the imported content as it has to be "the source of truth". Couldn't we manage this only on client side?

}

public formatRequestContent(requestContent: string): string {
const normalizedContent = normalizeLineEndings(requestContent);
Copy link
Member

Choose a reason for hiding this comment

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

Yes, if we're doing this here, there's no need to do it on server side IMO.

@SebastienDegodez
Copy link
Member

Is it possible to only handle this on client side to keep the imported artifact as the source of truth? I wouldn't expect changes on server side importer.

I just want to confirm: when you say client, do you specifically mean the JavaScript client?
If so, wouldn’t the same issue still occur when uploading through the REST API (e.g., via the test container), since the server-side importer wouldn’t change?

@lbroudoux
Copy link
Member

I just want to confirm: when you say client, do you specifically mean the JavaScript client? If so, wouldn’t the same issue still occur when uploading through the REST API (e.g., via the test container), since the server-side importer wouldn’t change?

Yes, I mean on the JavaScript side only. IIRC, the problem we face is only for generating a correct CURL command - it does not impact mock features. So I would only change this part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Carriage return characters (\r) in SOAP payloads cause validation errors

3 participants