Issue with default virtual host ( http:// ) on XML to JSON Policy

Not applicable

Added xml-to-json policy for "PostFlow", but it effects only secure host (https:// url), but not default host (http://)
why is it so? and how to solve it?
NOTE: Please let me know if you need anything else.

Solved Solved
0 11 194
2 ACCEPTED SOLUTIONS

rmishra
Participant V

Check if your proxy is deployed to the default virtual host.

For your request to be handled at both virtual hosts. In your ProxyEndpoint, configure something similar to

 <ProxyEndpoint name="default">
	<HTTPProxyConnection> 
		<BasePath>/path</BasePath> 
		<VirtualHost>secure</VirtualHost> 
		<VirtualHost>default</VirtualHost> 
	</HTTPProxyConnection> 
</ProxyEndpoint>

View solution in original post

HI @Naga Vadlapudi

The way http://mocktarget.apigee.net/xml works is that if the services gets the same request call, it returns a 304 with ETag (cache header). The browser caches the info and returns that there is no change to the response, so the client just shows the cached response. And for this response, the Content-Type is not set and the content length is 0 as well (You can find it in trace), hence the XML to JSON policy does not execute as expected.

However this works in POSTMAN because Postman adds a token to every call you make, so the backend treats each as a separate request. Hope that clarifies !

This has nothing to do with the client you use, its just that the backend response differs with the calls coming in and the clients manipulates accordingly

View solution in original post

11 REPLIES 11

rmishra
Participant V

Check if your proxy is deployed to the default virtual host.

For your request to be handled at both virtual hosts. In your ProxyEndpoint, configure something similar to

 <ProxyEndpoint name="default">
	<HTTPProxyConnection> 
		<BasePath>/path</BasePath> 
		<VirtualHost>secure</VirtualHost> 
		<VirtualHost>default</VirtualHost> 
	</HTTPProxyConnection> 
</ProxyEndpoint>

Thank you for responding. Here is the config, I did the same but it's not working with virtual host, and it is working fine with secure host again.

<?xml version="1.0" encoding="UTF-8"?>
<ProxyEndpoint name="default">
   <Description />
   <FaultRules />
   <PreFlow name="PreFlow">
      <Request>
         <Step>
            <Name>Spike-Arrest-1</Name>
         </Step>
      </Request>
      <Response />
   </PreFlow>
   <PostFlow name="PostFlow">
      <Request />
      <Response>
         <Step>
            <Name>XML-to-JSON-1</Name>
         </Step>
      </Response>
   </PostFlow>
   <Flows />
   <HTTPProxyConnection>
      <BasePath>/helloworldpolicies</BasePath>
      <!--<Properties/>-->
      <VirtualHost>secure</VirtualHost>
      <VirtualHost>default</VirtualHost>
   </HTTPProxyConnection>
   <RouteRule name="default">
      <TargetEndpoint>default</TargetEndpoint>
   </RouteRule>
</ProxyEndpoint>

Go to the overview tab of the proxy, does it show deployed on an HTTP endpoint?

Do you get a response from the HTTP Endpoint?

6902-apigee-issue.jpg

yes.
I got response from http and https, but I am expecting JSON response from both of them, as I implemented XMLtoJSON policy.
Problem is, http returns XML response, and https returns JSON response always.

Have you traced it? Does the XML to JSON policy execute in both cases? If it is skipped, why is it skipped? Tracing should tell you all that

Also, Is the content-type of the request same for both HTTP and HTTPS?

oh yeah, tracing provides the flow, it's working now. I think it takes a while to apply the policy or something. Please let me know, are there any chances of delay in policy implementation by apigee?



Thank you.

Nope. No chance of a delay to one vhost and not another, and I've never heard of such a case. I'd expect there is some other explanation for what you saw.

One possible explanation for what you saw (different responses coming from different vhosts): if you changed the basepath of the proxy at the same time you added or removed a vhost, then re-deployed the proxy, you could have multiple revisions of the proxy deployed at the same time. And in that case, what you observed might be correct behavior that you had not expected, because you didn't take into account the possibility of different basepaths affecting your tests this way.

ps: I think it's generally a bad idea to rely on the "default" http vhost.

In fact I think we (Apigee) should relable it to be "insecure" and should officially discourage people from using it.

Not applicable

Thanks to @rmishra and @Dino-at-Google for taking time to go through the issue.

	Solution is silly, but not ignorable.


Issue: Chrome, some how is not likely to display json (but displays response in xml format) for virtual host for a very long time ( even after >15 min). I am relying on chrome browser to hit urls and check json response.


Solution: Tracing gave me what I expected, postman gave me what I expected. But chrome failed to return json response instead it is returning xml response, this may be due to my custom modifications on chrome.


Conclusion: So, after this experiment I strongly recommend to use "postman" rather than chrome to test, REST apis.

Thank you.

HI @Naga Vadlapudi

The way http://mocktarget.apigee.net/xml works is that if the services gets the same request call, it returns a 304 with ETag (cache header). The browser caches the info and returns that there is no change to the response, so the client just shows the cached response. And for this response, the Content-Type is not set and the content length is 0 as well (You can find it in trace), hence the XML to JSON policy does not execute as expected.

However this works in POSTMAN because Postman adds a token to every call you make, so the backend treats each as a separate request. Hope that clarifies !

This has nothing to do with the client you use, its just that the backend response differs with the calls coming in and the clients manipulates accordingly

Nice catch, Sai!

Wow, Great catch. Completely missed this !!