Switching between Classic and New proxy editor (v4.15.07.01) introduces garbage characters in policy XML?

Not applicable

I have imported many API proxies from an on-prem 4.14.04 installation to on-prem 4.15.07(.01) installation. For a specific set of policies (associated with many of the migrated proxies), I see the following behavior when switching between the Classic and New versions of the Proxy Editor:

For Classic, everything appears normal:

1631-rqpaclassic.png

When I switch to New version of the Proxy Editor, errors are introduced:

1632-rqpanew.png

This does not seem to cause any errors in policy processing; however, I have difficulty believing this would be expected behavior.

Has anyone else observed this? Any known causes? Resolutions (other than manual edit of policy XML)?

Solved Solved
4 6 510
1 ACCEPTED SOLUTION

Not applicable

Thank you Jason,

this is a known bug due to some space characters not recognized in the new editor. This has been fixed in our code base and it is already in our public cloud version. I need to look at when this will be available for Private Cloud.

View solution in original post

6 REPLIES 6

Not applicable

Thank you Jason,

this is a known bug due to some space characters not recognized in the new editor. This has been fixed in our code base and it is already in our public cloud version. I need to look at when this will be available for Private Cloud.

Thank you, @oponce@apigee.com

hi oponce@apigee.com, I'm using free account of apigee edge.

I am facing the same issue. In my AssignMessage policy my payload contains HTML tags as a JSON attribute's value:

for ex:

{

"div":"<h2>text</h2>"

}

If I'm trying to save this it with new proxy editor gives error as:

"Bundle is invalid. The content of elements must consist of well-formed character data or markup."

So is it the same issue? How to resolved it?

Not applicable

Hello @Sonali,

It is in deed a similar problem, but not the same. We also have seen it and we'll fix it for our next cloud release. Thank you for telling us.

As a work around, I'ld suggest to use a javascript policy to set a context variable and then use it in the AssignMessage policy. Doing so you can also add some logic there in case you need it.

Thank you!