mulesoft / api-policies

18 stars 34 forks source link

Request Response Logging policy changes for compatibility with GW 2.0 #4

Closed jesica-fera closed 9 years ago

jesica-fera commented 9 years ago

I've seen the modifications you've done to this policy to work in 2.0. Most of the things are now working but there are still some changes to do: 1) "http.headers" does not exist anymore with new HTTP transport, all the inbound properties referenced from this map should be referenced directly: message.inboundProperties[http.headers]['Host'] -> message.inboundProperties['Host'] 2) MULE_REMOTE_CLIENT_ADDRESS should be replaced with http.remote.address 3) "http.context.uri" should be replaced with "Host" and "http.request" with "http.request.uri""

All these new constants are in org.mule.module.http.api.HttpConstants class

rusinm commented 9 years ago

Thanks for the comments. From your list: 1) done 2) I get no http.remote.address in HTTP request headers but MULE_REMOTE_CLIENT_ADDRESS yes 3) I get no http.request.uri in HTTP headers

This is a snippet of request inboud properties from printing #[message] to the console with my local 2.0 runtime:

INBOUND scoped properties: Accept=/ Accept-Encoding=gzip, deflate Accept-Language=sk-SK,sk;q=0.8,cs;q=0.6,en-US;q=0.4,en;q=0.2 Cache-Control=no-cache Connection=true Content-Length=4 Content-Type=text/plain;charset=UTF-8 Host=localhost:8083 Keep-Alive=true MULE_ORIGINATING_ENDPOINT=endpoint.http.0.0.0.0.8083 MULE_REMOTE_CLIENTADDRESS=/127.0.0.1:51941 Origin=chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm User-Agent=Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 http.context.path=/ http.context.uri=http://0.0.0.0:8083 http.headers={Accept-Language=sk-SK,sk;q=0.8,cs;q=0.6,en-US;q=0.4,en;q=0.2, Host=localhost:8083, Content-Length=4, Accept-Encoding=gzip, deflate, User-Agent=Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36, Keep-Alive=true, Origin=chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm, Connection=true, Content-Type=text/plain;charset=UTF-8, Accept=/_, Cache-Control=no-cache} http.method=POST http.query.params={} http.query.string= http.relative.path=info http.request=/info http.request.path=/info http.version=HTTP/1.1

4) 1.3.2 version sent X-* HTTP headers. There are none in 2.0, so i assume it is correct to remove those from the policy, right?
5) I was told to enable analytics, I need to add these attributes to 'policy' XML element: id="{{policyId}}" policyName="Request/response Logging" When I look at the applied policy in my local GW, policyName is absent. Is it expected behavior? Originally, I extracted analytics data from __httpEvent invocation property. There is no such in 2.0. Where can I access analytics data? Furthermore, I see no change in charts in Anypoint Platform Analytics section so I guess the data is not gathered.

jesica-fera commented 9 years ago

Hi! Quick question, are you using HTTP Listeners (the new Mule 3.6 HTTP Connector) to test this? http-endpoints are deprecated in 2.0, so GW will only work with listeners. From what I see in the snippet you pasted they seem to be the deprecated headers. About your questions: 4) Some X- headers are still sent, the ones that have been removed are X-MULE headers (But I think this policy does not use them) 5) You cannot see policy name because the change is not in production yet, only in QA env (from the Platform side). On the 13th will be in production About httpEvent variable, it should be present for 2.0 too. It's the Api tracked in the portal? Analytics events are only sent in that case. Otherwise you won't see neither httpEvent or any data sent to analytics.

rusinm commented 9 years ago

I update the proxy app to use the new version of HTTP connector and I got the headers you described. The analytics events arrived. Thanks for your helpful comments.