I'm moving my development to one tomcat in docker.
I have two environments in RestClient, one using the tomcat in local and the other for the Dockered.
The first issue I had was resolved, it was the one for invalid characters in the request.
Now the issue is in the response. From the request, I receive the code 200, using the local tomcat I receive the body but using the Dockered, I did not. It happens in some requests but I have other endpoints sending the body with no issue.
Did somebody found something similar?
Thanks in advance for your help
Regards,
Related
I implemented a kie-server on Wilfly and deployed a decision service.
Calling it on the same machine with Insomnia works fine, Just using http://localhost:8080.
Trying to make the same call from another machine using xx.xxx.xxx.xxx:8080 just runs into a timeout.
What am I doing wrong?
Please help.
Issue solved using portlistener.exe
Still wonder why the port is not opened by the server. Kie server claims it is.
Now I have another issue. See next question.
We are running a few aspnet core APIs in a docker swarm with nginx as the reverse proxy server.
We have been running this set up for a while without any issue. However recently we added an SSL certificate that we got from letsencrypt. Since then we notice that after we hit the /api/TokenAuth/Authenticate endpoint and get assign a Bearer token if we try and make a subsequent call using the token that was just assigned, the call sometimes fail and we get a 302 (it works about 40% of the time). It seems that if we try using that same token again after some time has passed than the call works.
It's strange that this only seems to be an issue if we have ssl(https) on.
I cannot replicate the issue locally. It seems to only show up when the api is deployed to our docker swarm (which is running nginx and the api as containers, nginx handles the ssl cert).
Does anyone have any idea what the issue might be? Has anyone experienced something like this before that could point me in the right direction?
There are two console below: The top one is an example of it working and I got the expected results back. The bottom is the response when it fails.
I found the issue. We have 3 instances/replica of api that is set to issue the Token. The server time on each server seems to be off by seconds. Therefore if the server that issues the token is ahead of the server that processes the subsequent request, then the token is not valid yet.
We have two jira installations at our company. One that we use for our projects and a second one for testing purposes.
I'm working in a project that needs to use the JIRA REST API. For this purpose I'm connecting to our testing instance.
The problem is that while trying out the REST API, I keep getting 400 errors without a single explanation of what went wrong. I just get an HTML with
Your browser sent a request that this server could not understand
I was a bit desperate and decided to try it into our real JIRA. To my surpirse the same request gave me a different response:
{"errorMessages":[],"errors":{"project":"project is required"}}
In this case, I do get a meaningful error!
I replicated this easily. I would never get a meaningful error from the test instance, but the real one will always give me one.
I cannot keep trying out stuff in our productive JIRA, but I cannot easily continue working without getting meaningful errors. So, what could be wrong in the testing instance? I could not find any configuration about the 'verbosity' of the API responses.
I believe that this error is returned not by JIRA but rather by proxy web server that is part of you production configuration.
I suggest you to compare HTTP headers that are sent with working requests from your browser with headers you pass via curl. Googling for the "Your browser sent a request that this server could not understand" helps too
I have a SOAP server/client application written in Delphi XE working fine for some time until a user who runs it on Windows 7 x64 behind a corporate proxy/firewall. The application sends and receives TSOAPAttachment object in the request.
The Problem:
Once the first request from this user is received and processed, the server could not process any request (from any user) successfully coming after this.
The server still response to the request, but the SOAPAttachment of the request
seems corrupted after the first one from this user, that's why it couldn't process the request successfully.
After putting may debug logs to the server, I noticed the TSOAPAttachment.SourceStream in the request's parameter become inaccessible (or empty), and TSOAPAttachment.CacheFile also empty. Therefore whenever trying to use the SourceStream, it will return Access Violation error.
Further investigation found that the BorlandSoapAttachment(n) file generated in the temp folder by the first request still exist and locked (which should be deleted when a request is completed normally), and BorlandSoapAttachment(n+1) files of the following request are piling up.
The SOAP server will work again after restarting IIS or recycle the application pool.
It is quite certain that it is caused by the proxy or the user’s networks because when the same machine runs outside this networks, it will work fine.
To add more mystery to the problem, running the application on WinXP behind the same proxy have no problem AT ALL!
Any help or recommendation is very appreciated as we have stuck in this situation for some time.
Big thanks in advance.
If you are really sure that you debugged all your server logic that handles the attachments to attempt do discover any piece of code that could failed specifically on Windows 7, I would suggest:
1) Use some network sniffer Wireshark is good for this task, make two subsequent requests with the same data/parameters values, and compare the HTTP contents. This analyze should be done both in the client (to see if the data is always leaving the client machine with the same content) and also in the server, to analyze the incoming data;
2) I faced a similar situation in the past, and my attempts to really understand the problem was not well succeed. I did workaround the problem sending files as Base64 encoded strings parameters, and not using the SOAP attachments. The side affect of using Base64 its an increase of ~30% in the data size to be sent, and this could be significant if you are transferring large files.
Remember that SOAP attachments create temp files in the server, and Windows 7 has different file access rules than Windows XP. I don't know if this could explain the first call being processed ant the others not, but maybe there are something related with file access.
Maybe it is UAC (User Access Control) problem under Win 7. Try running the client in win 7 "As Administrator" and see if it is working properly.
I have started using the websocket php example in http://code.google.com/p/phpwebsocket/ It works pretty well on localhost but unfortunately, no client other than localhost can connect to the websocket server. And whenever I change the path to something like http://10.27.50.25:8787/client.html, it does not let the client to connect. Does anyone have any idea/sample about how to fix it?
Thanks in advance
Could be a crossdomain problem. Modern browsers prevent access to hosts other than the one where the page loaded from. You can get around it by providing JSON as an output then using jQuery Ajax JSON parsing.