I am trying to develop a client application that calls a RESTful web service. As part of a RESTful design, the service uses a variety of HTTP status codes to communicate state back to the caller. For instance, if I request a resource that doesn't exist, the service responds with a 404 status code. Likewise, if I pass in malformed parameters, the service responds with a 400 (Bad Request) status code. Silverlight 5 automatically converts these into WebExceptions. Is there anyway I can get SL to not throw exceptions but return a legitimate response object with the status code, etc set to the what was received so that I can decide how to handle the response in my code?
(To further clarify, it appears this is only the case for status codes in the 400 and 500 ranges.)
AFAIK, there is no solution to avoid exceptions. Worse than that, it might be hard or even impossible to get the actual HTTP code (I'm not certain there, I haven't tried too hard).
You'll probably want to develop an HTTP request tool that traps WebException and provide an error status to the caller.
Related
I am using fetch in a NodeJS application. Technically, I have a ReactJS front-end calling the NodeJS backend (as a proxy), and then the proxy calls out to backend services on a different domain.
However, from logging errors from consumers (I haven't been able to reproduce this issue myself) I see that a lot of these proxy calls (using fetch) throw an error that just says Network Request Failed, which is of no help. Some context:
This only occurs on a subset of all total calls (lets say 5% of traffic)
Users that encounter this error can often make the same call again some time later (next couple minutes/hours/days) and it will go through
From Application Insights, I can see no correlation between browsers, locations, etc
Calls often return fast, like < 100 ms
All calls are HTTPS, non are HTTP
We have a fetch polyfill from fetch-ponyfill that will take over if fetch is not available (Internet Explorer). I did test this package itself and the calls went through fine. I also mentioned that this error does occur on browsers that do support fetch, so I don't think this is the error.
Fetch settings for all requests
Method is set per request, but I've seen it fail on different types (GET, POST, etc)
Mode is set to 'same-origin'. I thought this was odd, since we were sending a request from one domain to another, but I tried to set it differently and it didn't affect anything. Also, why would some requests work for some, but not for others?
Body is set per request, based on the data being sent.
Headers is usually just Accept and Content-Type, both set to JSON.
I have tried researching this topic before, but most posts I found referenced React native applications running on iOS, where you have to set some security permissions in the plist file to allow HTTP requests or something to do with transport security.
I have implement logging specific points for the data in Application Insights, and I can see that fetch() was called, but then() was never reached; it went straight to the .catch(). So it's not even reaching code that parses the request, because apparently no request came back (we then parse the JSON response and call other functions, but like I said, it doesn't even reach this point).
Which is also odd, since the request never comes back, but it fails (often) within 100 ms.
My suspicions:
Some consumers have some sort of add-on for there browser that is messing with the request. Although, I run with uBlock Origin and HTTPS Everywhere and I have not seen this error. I'm not sure what else could be modifying requests that would cause it to immediately fail.
The call goes through, which then reaches an Azure Application Gateway, which might fail for some reason (too many connected clients, not enough ports, etc) and returns a response that immediately fails the fetch call without running the .then() on the response.
For #2, I remember I had traced a network call that failed and returned Network Request Failed: Made it through the proxy -> made it through the Application Gateway -> hit the backend services -> backend services sent a response. I am currently requesting access to backend service logs in order to verify this on some more recent calls (last time I did this, I did it through a screenshare with a backend developer), and hopefully clear up the path back to the client (the ReactJS application). I do remember though that it made it to the backend services successfully.
So I'm honestly not sure what's going on here. Does anyone have any insight?
Based on your excellent description and detective work, it's clear that the problem is between your Node app and the other domain. The other domain is throwing an error and your proxy has no choice but to say that there's an error on the server. That's why it's always throwing a 500-series error, the Network Request Failed error that you're seeing.
It's an intermittent problem, so the error is inconsistent. It's a waste of your time to continue to look at the browser because the problem will have been created beyond that, either in your proxy translating that request or on the remote server. You have to find that error.
Here's what I'd do...
Implement brute-force logging in your Node app. You can use Bunyan, or Winston or just require(fs) and write out to some file when an error occurs. Then look at the results. Only log it out when the response code from the other server is in the 400 or 500 ranges. Log the request object and the response object.
Something like this with Bunyan:
fetch(urlToRemoteServer)
.then(res => res.json())
.then(res => whateverElseYoureDoing(res))
.catch(err => {
// Get the request & response to the remote server
log.info({request: req, response: res, err: err});
});
where the res in this case is the response we just got from the other domain and req is our request to them.
The logs on your Azure server will then have the entire request and response. From this you can find commonalities. and (🤞) the cause of the problem.
What I am trying to achieved is:
Send http 102 to client who requested somedoc.html
Some processing on the side including out of band authentication
If authenticated, send response built from somedoc.html, otherwise generic not auth message
I'm having a failure of understanding somewhere, in that I cannot seem to figure out how to send the 102 and save the connection details so that I can forward the response in step 3. I had thought I could queue a response then either enter a wait loop or suspend the connection, but as far as I can tell I have to return from the MHD_AcceptPolicyCallback for the response to be sent, then I cannot figure out how to get back to the connection. I have looked at the request completed call back but this still results in the 102 not being sent.
I really can't figure out a process to achieve these steps from the examples or the manual and any help would be appreciated.
HTTP standards doesn't define response code 102.
See https://www.rfc-editor.org/rfc/rfc7231#section-6
and https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1
HTTP protocol use request-response logic. If you already responded to some request then you can't add another response later to the same request.
After talking with the developer, the 102 status code was defined "for completeness"; however, no attempt has been made to implement the required functionality to actually be able to use this status code in a meaningful way on a server developed with the libmicrohttpd library.
I have an AngularJS application that talks to various java services. In the application I have a global http header setting in an http interceptor. That means all the service requests from my application will get the header values.
Now the trouble is that all the services CORS settings won't allow this header value. Couple of services does, while others does not. The service calls to the servers that do not support the header fails, since the http interceptor always puts the header values.
Is there a better way to design, in the above said case, so as to avoid the issue stated?
Appreciate any help...
How about adding a response interceptor, looking for a 401 status? If you get a 401, attempt to do the same request again without the headers this time. If this succeeds, 'whitelist' this domain to make all following requests without the headers that you don't want.
Otherwise, if you have a limited number of services that you are making calls to, maybe whitelist them inside of your request interceptor? This would probably be easier, but it's not very elegant.
When calling a web service from Force.com, I am getting:
System.CalloutException: Web service callout failed: Unexpected
element. Parser was expecting element
'http://schemas.xmlsoap.org/soap/envelope/:Envelope' but found ':HTML'
The network guys at the other end has asked to see the full response that Salesforce is getting from their server.
Is there a way to achieve that? I have tried running with debug level 'Finest' from execute anonymous, but that yields the same little message with no further detail.
The message you are getting is because an error is generated as Saleforce is trying to parse the response is and it isn't logged unfortunately.
The parsing error is happening because instead of a SOAP message response you are getting an HTML page. This usually happens when you are accessing a service that is protected behind a firewall. Which means you may be able to see the service when browsing on your computer but remember that Salesforce is outside of your firewall and thus any communication by Salesforce to your service will be blocked.
Couple of ways to address this but this wiki topic from Salesforce best covers the options:
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging_security.htm
The above is specific to outbound messaging but essentially the technology issues are the same.
Don't forget that Apex includes an HttpRequest Class that works as a lower layer than the SOAP APIs. You should be able to write up a test method that sends a hard-coded XML request to the server and dumps the HttpResponse so you can see it.
Adding my own best answer, based on some internet research:
You can use an external tool like Runscope as a webservice proxy to automatically forward requests and pass through responses and view the XML SOAP messages. This is not a native solution on SFDC but it does do the job.
https://www.runscope.com/
The issue is that Force.com is trying to parse a SOAP response that's actually just HTML. This happens sometimes when an error occurred server-side and the response is meant for a browser to display, rather than sending back an exception report via a properly formatted SOAP response.
If they can't figure out why they are not sending back a consumable SOAP response, then you can try using other tools (outside of Force.com) to make the same webservice call from your browser and then see what the HTML actually says on return.
My web application uses ajax and i check request is ajax request or not via php codes. If not then i generate 404 error otherwise run php codes that associated ajax function.
If user or search spider tries to reach ajax function page(ex: /books/ajax/books_list) web app return 404 not found status code and i see a lot of 404 errors in google webmaster tools.
I should change 404 status code but which one is right for this condition ? Can be "406 not acceptable" ?
I think 403 (Forbidden) probably best describes it. The resource is there, but you've determined that you're not going to give access to that resource, and even authenticating the user isn't going to help.
I would suggest that you return the 406 you suggested. The only alternatives worth considering are '501 not implemented'
The server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource
And '403 Forbidden'
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not
wish to make this information available to the client, the status
code 404 (Not Found) can be used instead.
Not sure how you determine whether it's a proper Ajax request. If you expect it to be POST, but the spider uses GET, then it should be 405 (Method Not Allowed).
You should not be using 406: it means "not acceptable", in the sense that you cannot support the HTTP Accept: headers that the browser sent. This would likely be incorrect (as you likely aren't checking the Accept headers at all).
If you really reject the request because it comes from an unauthorized client, then 403 is appropriate.
It's my understanding that SE spiders get a little skittish if they see errors that indicate server problems. (A 406 can indicate a badly implemented server.) A 404 doesn't describe what you're looking for, as the resource is there, but a 403 (forbidden) just lets the spider know that this page isn't for them. You can also use your robots.txt file.