I speack spanihs. Will try english.
I have a WSO2 proxy service for a backend SOAP WebService. It works fine!
The problem starts when i enable Response Caching for the proxy service, 20 seconds caching.
I set ports in TCPMonitor(localhost 8280 and the one for backend service).
I see that when i send different requests to the proxy, it returns same cached response. It return the response cached for the first request into that 20 seconds of life into the cache.
Differents body http for different requests, but same headers and POST URI.
Does ESB do the hash with headers+body or only the headers?
Thansk for your help
Diego
Are you suing cache mediator?
cache mediator caches the response, whenevr it sees same request comes to the system, it sends back the cached response.
Or else did you enable the response caching fro proxy services?
Related
I am using a cache mediator inside the proxy, that proxy I am calling the inside sequence(I need to use cache into several API that's why I am calling that proxy inside sequence). then I am calling into the rest API.
Issue: when I am hitting the rest API services through postman, cache is not working.
the same services I am hitting from SoapUI, cache is working fine(second time onwards the response is coming from cache storage).
it's chrome also it's working.
I believe Postman sends a random token in every request. Postman-Token: <Token>. Cache mediator works by checking the headers and payload of the request. When a random header value is sent every time, cache mediator will diagnose it as a different request. Hence the response won't be served from the Cache.
To overcome the issue add the "Postman-Token" header in the cache mediator configuration under <headersToExcludeInHash/>
https://docs.wso2.com/display/EI660/Cache+Mediator
I read Http spec. but I have a doubt and I hope someone can help me.
When a cache receives a request and has a stored response that must be validated (before being served to the received request), does the cache send the received request (adding the conditional header fields it needs for validation) to the next server OR does the cache generate a new request (with conditional header fields it needs for validation) and send the generated request to the next server?
Thank you very much! :)
I think the idea is that the client would issue the request with the key headers, and the server would either respond with the content or a 304 to use whatever was in the local cache.
This behavior should be the same for upstream caches along the network path all the way to the source of truth.
"When a cache receives a request..."
Cache doesn't receive HTTP request. It is user-agent (browser) that check cache to see whether there is any cache entry matched for an HTTP request. Cache itself is just a bunch of data stored in disk/memory.
"Does the cache send the received request...OR does the cache generate a new request..."
Cache doesn't send HTTP request. It is user-agent (browser)'s job to send the request.
In summary, cache is just bytes of data, it doesn't know when and where HTTP request is sent. All cache validation logic (cache related HTTP headers) is implemented by user-agent.
Lets say we have other domain with API for get user by ID
web.com/id=5
My server localhost:1337 do request on this API...
request.get(...web.com/id=5...)
And gets response with all data.
But GET ajax request from client browser with same localhost:1337 dont work like that.
I hear about cross-origin but why my server dont care?
In general, APIs allow Cross Domain requests. They do this by using this header:
Access-Control-Allow-Origin: *
This header works for most cases, but there are additional headers used when dealing with custom headers, or non get/post requests.
I have one question. Recently i have get link from my streaming server to play in my website. My streaming server use http link but my website use https ssl. During i get the link to play it cannot get content from my streaming server by show the following error:
enter image description here
I am looking forward to hearing from all of you soon.
Thanks in advance.
Best Regards,
Chhenghong
This error happens because you cannot access HTTP resource from HTTPS page, for security consideration. It is the browser behaviour.
To fix this issue, a proxy endpoint can be made in server side, such as /proxy/playlist.m3u8, which accept HTTP GET request. The browser will fetch the resource from https://<your-server>/proxy/playlist.m3u8, as if it is stored in your host. As it is an HTTPS request, no error.
In the server side, when GET request to /proxy/playlist.m3u8 is listened, the HTTP request would be proxied to your streaming server (send GET request to the streaming server with all headers, parameters and body). When the response from streaming server is received, the response would be returned to browser directly, with all response headers and data.
As the HTTP request to streaming server happens in your server side, the restriction logic from browser does not apply any more.
For example, if the server is written in Node.js, with Express and request module, the proxy endpoint would look like:
app.get('/proxy/playlist.m3u8', function(req, res) {
req.pipe(request('http://<streaming-server>/path/playlist.m3u8')).pipe(res);
});
A CORS POST request (AJAX) made by my client server (running on Apache # port 443) to my REST server (running on Tomcat # port 8443), fails to trigger when tried over HTTPS.
Please note that all the requests function properly without SSL.
I have already set the withCredentials: true options in the request fields. And my Tomcat server also takes care of the appropriate headers :
response.addHeader("Access-Control-Allow-Origin", "https://localhost");
response.addHeader("Access-Control-Allow-Credentials", "true");
response.addHeader("Access-Control-Allow-Headers", "Content-Type");
response.addHeader("Access-Control-Allow-Methods", "OPTIONS, POST");
I also tried using Curl, but the issue persisted over SSL. However, the Tomcat server responds to all my requests when tried directly over Postman/through the browser.
Could someone tell me what I'm missing out here?
I'm assuming this is an issue with the preflight request. There are two types of CORS requests: simple, and not-so-simple.
The simple kind is either a GET or POST with no custom headers whose content type is "text/plain".
The not-so-simple kind is any request using custom headers, utilising request methods other than POST or GET, and using different content body types. These requests will be "preflighted"; that is the browser will make a preflight request on the clients behalf in order to determine whether or not the server will allow this request. The preflight request uses the OPTIONS method. I'm willing to bet if you use something like Firebug to have a look what's going on you'll see something like this in the Net tab: "OPTIONS activity" with a status of "Aborted".
Unfortunately the preflight request doesn't pass the client certificate to the server which is why your request is failing to trigger. You need to disable two way SSL in order to get it working. In Apache you can try changing the SSLVerifyClient to:
SSLVerifyClient optional
I've used this before in order to get my cross domain AJAX calls working over HTTPS.
Good luck.