We have a WCF Service that is working fine, there are 4 customers using this service without problems, but I have this one customer who is complaining that he can't call the webservice anymore for the last few days.
We did not change anything since October and he also claims he did not change anything.
As I said, I have other customers using this service just fine and we also can call the service from SOAP UI. We even tried to create a new isolated machine in AWS and call the service in order to make sure it is not something like a firewall issue blocking the communication from outside our network.
For what I can see from the stack trace he sent me, this customer uses Sonic ESB to call our service. I really don't understand how Sonic ESB works but my guess is that the error is caused by Sonic ESB, not my service. It is like it creates an "adapter" in between his application and my service.
Which led me this following conclusion:
1) Looking at his request XML (he sent me) I can see that it does not match the WSDL I have provided, for instance:
(I have changed few names and values for obvious reasons)
<CreateOrderGatewayCompanyName> --> This would be just CreateOrderGateway
<header> --> this header seems specific to Sonic ESB, nothing to do with us
<user>123414714</user>
<idProcess>5411251</idProcess>
<channel>EB</channel>
<ip>[ip number here]</ip>
<sessionId>1fd5a3f4d8f4dsa5f4dsaf4dsf1da5.xyz</sessionId>
</header>
<body>
<idCampania>xyz</idCampania> --> This would be "CampaignId"
...
<order>
...
<fecha>2016-12-21</fecha> --> This would be "Date"
...
</order>
</body>
</CreateOrderGatewayCompanyName>
So I can only conclude that somewhere in the process, the ESB will convert this weird XML in the proper SOAP request format my service is expecting.
2) Looking at the exception stack trace he sent me, I can see this 404 error:
<?xml version="1.0" encoding="UTF-8"?>
<exception xmlns="http://www.sonicsw.com/sonicesb/exception">
<message>Exception while retrieving soap envelope from response:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Not Found</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Not Found</h2>
<hr><p>HTTP Error 404. The requested resource is not found.</p>
</BODY></HTML>
</message>
<class>com.sonicsw.xqimpl.invkimpl.wsif.providers.axissoap.SoapProviderInvocationException</class>
<detail/>
<stackTrace><![CDATA[org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
...
And here is the thing, this 404 HTML code that he is getting as a response DOES NOT come from my server because we use IIS 8.5 and the 404 error page of IIS does not look like this one, the HTML is different and the message is different as well. It would be something like:
“404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed,..”
So does anyone know if this Sonic ESB actually creates an adapter or proxy in the middle of the applications? And if someone already have experienced an error like this what would be the cause? I'm 100% positive my service is working fine.
Did your customer sent the actual soap request that is being sent?
He can enable the actual webservice invocation (the easiest way is to do it from the admin console).
http://knowledgebase.progress.com/articles/Article/S6498
After knowing the exact soap request that it is being sent, it will be easier to debug.
Also I recommend that you enable for some minutes the traces of requests in your server when he tests to discard that any other modifications are done in the middle.
It turns out that a network trace (wireshark) on my server revealed that my customer's proxy was modifying the "Host" of the request, for instance, instead of
Host: ourdomain.com
It was modified like
Host: proxy.customer.com:8080
So when this request arrived at the IIS server, the binding was configured to "ourdomain.com" and then it dropped the request. For some weird reason, a guy named "Microsoft HTTPAPI" returned the reply with that 404 error page my customer was getting on their application.
So we have fixed the problem changing our IIS bindings because I don't want to wait my customer to investigate what the hell is his proxy doing with the host name.
Related
I have developed my API and registered in mule API Manager.
When my API is down and trying to hit the API from Postman tool getting below error.
<html>
<head>
<title>504 Gateway Time-out</title>
</head>
<body bgcolor="white">
<center>
<h1>504 Gateway Time-out</h1>
</center>
<hr>
<center>nginx</center>
</body>
</html>
Ideally it should be 503 – Service unavailable. Any options to get error code 503 instead of 504 ?
If you API in API manager is down, there is nothing you can do. If your backend implementation is down you could do something will policies to override the status code.
But as your API in API manager is down, there is nothing in your control.
504 is still technically valid as nginx is acting as a proxy and it cannot reach your API.
But I would not worry about it. all API client should handle 5XX status code the same. As in 'Server Error' and can possibly be retried later.
Also with API down in API manager, the 504 should take a while to get a response back. So I would probably set a decent request timeout before reaching that point.
That really isn't in your control. The difference between 503 and 504 is that 503 means that your app-server has issues, while 504 means that the gateway you're using has issues.
For example, if I am using nginx as a gateway, and I'm redirecting to some app server. If the app server is down, then nginx will return 503.
If, however, the app server is unresponsive, or if nginx itself is failing (due to load, or other issues), the response will be 504.
In general, you shouldn't be worried about what the response is. 5xxs are treated roughly the same in most situations, and they mean server issues.
I am having one webservice to sync order data from Ipad offline app to live server. Sometimes webservice is working fine but sometimes it is not.
So when I am trying to call that webservice to resolve the issue through url using Postman, I am getting below error.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>414 Request-URI Too Long</title>
</head>
<body>
<h1>Request-URI Too Long</h1>
<p>The requested URL's length exceeds the capacity
limit for this server.
<br />
</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at ip-172-31-31-143.ap-southeast-1.compute.internal Port 80</address>
</body>
</html>
Please provide me the solution. Thanks in advance.
The Web server (running the Web site) thinks that the HTTP data stream sent by the client (e.g. your Web browser or our CheckUpDown robot) contains a URL that is simply too large i.e. too many bytes.
Typically Web servers set fairly generous limits on length for genuine URLs e.g. up to 2048 or 4096 characters. If your URL is particularly long, you can usually try shorter variations to see roughly where the limit is. If your long URL is indeed valid, then the Web server may need to be reconfigured to allow your URLs through. Understand that Web servers have to set some reasonable limit here, because they have to deal with badly programmed clients trying to give them huge garbage URLs.
Fixing 414 errors - general
This error seldom occurs in most Web traffic, particularly when the client system is a Web browser. The URLs in this case are typically standard hyperlinks found on Web pages. These links tend to be too large if they are simply wrong i.e. the Web page containing the link has been badly coded.
If your client system is not a Web browser, the problem can only be resolved by examining what the client is trying to do then discussing with your ISP why the Web server rejects the size of the URL sent by the client system.
WSO2 Identity Server 5.0.0
For things such as a 500 errors and anything unforeseen, I'd like to configure my Identity Server instance to have our own branded error page to hide the server technology for security reasons and also just allow the error a little confusion.
At any rate, this no help: https://docs.wso2.com/display/IS500/Customizing+Error+Messages
I tried editing /repository/conf/tomcat/carbon/WEB-INF/web.xml and added the standard way to define an error page for exceptions:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/NiceError.jsp</location>
</error-page>
and then placed NiceError.jsp in /repository/conf/tomcat/carbon/
So when I make a 500 error reoccurr, things change, but I'm sent to the carbon management console login page. If I decide to login, I get served up with an 405 error like so:
HTTP Status 405 - HTTP method GET is not supported by this URL
type Status report
message HTTP method GET is not supported by this URL
description The specified HTTP method is not allowed for the requested resource.
Apache Tomcat/7.0.55
The URL looks like: https://hostname:9443/NiceError.jsp?sessionDataKey=eabd6c25-7c79-40a9-af87-3cd80a68367e&loginStatus=true
That doesn't help.
How can this kind of thing be setup to work? It can't be hard with the right information. Right? :)
The referred documentation page is to customize error messages for identity related errors as its name sounds. It is not to create custom error pages.
By the way if you need to create custom error page, which is applicable to all web applications in your server instance, you may need to add your error page to web.xml in /repository/conf/tomcat/ directory. It defines default values for all web applications loaded into your instance of Tomcat. As each application get deployed, above file is processed, followed by the /WEB-INF/web.xml deployment descriptor from your own applications.
Thanks
I originally asked the following question, to get some anwsers on how to handle special characters in an URL (GET) request for my Web Api:
Web Api 2 routing issue with special characters in URL
Encoding was obviously the way to go. But in order to get everything working, i had to do a pretty nasty workaround. And now, Im' at the point where i don't really understand why my workaround had to be done in the first place. So, the following is my setup:
A client can call my Web Api 2, Hosted on iis 8.5, by a get request containing an email in the URL. The most extreme example would be the following email:
!$%&'*+-/=?^_`{}|~#test.com
And yes, that sucker is a valid email, which therefore the API has to support. The URL pattern is as follows:
.../api/permissions/{email}/{brand}/
So a get request would be something along the lines of this:
.../api/permissions/#!$%&'*+-/=?^_`{}|~#test.com/economy
As the marked answer to my other question suggests, encoding this url is obviously a necessity. But this left me with a couple of other issues, such as "double escape of characters not allowed", and some specific "404 - not found" (routing could not pass the url). This i could mange to handle with the following settings for iis:
<system.web>
...
<httpRuntime requestPathInvalidCharacters=""/>
</system.web>
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true"/>
</security>
...
</system.webServer>
Now i was able to call my method with those pesky special characters, and everything was fine. But i hit another bump. The email specified above, #!$%&'*+-/=?^_`{}|~#test.com, resulted in a 404 - not found. An actual 404 - not found. The routing couldn't handle the request url:
[Route("{email}/{brand}"]
As I understand it, the iis decodes the request url, passes it on to the iis request pipeline, it is then picked up by the web api and run through the http message handlers before hitting the controller. In the controller, i could clearly see that the email part of the url was no longer encoded (provided i used a simple encoded email. the encoded email "#!$%&'*+-/=?^_`{}|~#test.com" still responded 404). I quickly figured, that the routing probably couldn't handle the fragmentation inside the url path, as the iis passes on a decoded url to the web api. So i had to get the url reencoded in the iis before handed on to the web api.
This i was able to make a workaround for, by using Url ReWrite. It reencoded that specific part of the url containing the email, and now the routing was handled properly with the special-character-email. The expected method was hit, and i could just decode the encoded email. To briefly sum up, this was the flow:
Request flow
Now, we have set up a LogMessageHandler which logs incoming requests and outgoing responses. When the logger logs the request.RequestUri, it is clear that the email is double encoded. But when the controller method is hit, it is only encoded once! So.. My question is, why do i have to reencode the URL in the iis for the routing to handle the request properly, when the url is already automatically encoded (and decoded again before hitting the controller)? Is this something i can configure? Can i somehow extend the scope of which the URL is encoded, all the way to the controller??
Regards
Frederik
Some of my site users are unable to call any api endpoints successfully whether through AJAX or a direct GET request in the browser. All HTML pages work fine. They get the following error when hitting an API endpoint.
--
--
What can be the issue here? I am suspecting some kind of firewall/ISP/Network restriction may be causing this, but I am not sure. What can I do to debug the issue? I checked my server logs and the request is hitting my server and the right response is being sent back. I am using rails 3.
UPDATE
Figured out the issue. The client's firewall is blocking application/json content.
The client's firewall is blocking all content of mime type application/json