I recently found that I can set the follow redirects as folase so that I can get to Location in the 302 response. But It goes to the fallBackFactory with exception feign.FeignException: [302 Found].
I read from another blog that if you want to stick with the 302 status code, you can change your Feign client definition to return a feign.Response
Can someone advise how do do this or any reference?
As mentioned I tried to set follow redirect as false it is still returning exception so I am struck how to overcome this
I Found the answer very straight forward.
import feign.Response;
#RequestMapping(method = RequestMethod.GET, value = "endpoint", consumes = "application/json")
Response apimethodname(#RequestParam String param1);
This way it does not go to FallBack and we have complete control to check the status.
Related
The F# Saturn web framework fails on retrieving a value for GET method when acceptJson is a part of pipeline.
Below a sample code that I run to reproduce the issue:
let api = pipeline {
plug acceptJson
set_header "x-pipeline-type" "Api"
}
let apiRouter = router {
not_found_handler (setStatusCode 404 >=> text "Api 404")
pipe_through api
get "/test" (text "Hello world")
}
let appRouter = router {
forward "/api" apiRouter
}
appRouter is then added in the use_router section of the application code.
When I'm sending the request with a header Content-Type:application/json the response is "404 not found". But if I remove plug acceptJson from the api pipeline definition I get a correct response.
How to make Saturn work with the plug acceptJson?
I suspect 3615 is right - this seems similar to a problem I just solved yesterday after beating my head against the wall for a week. A request to my app (just a straight app from "dotnew new Saturn") from my browser was accepted. But a request to the same url from a test method returned a 404. It boiled down to the fact that the test request was missing an "Accept" header. When I added "Accept text/html", it worked. What I deduced from that is that, if the app can't find a content type that will be accepted according to the request, then it will report a 404. Your situation is the same - you're trying to return Json, but the request didn't include an "Accept application/json", so it can't find any page that the request would accept.
Of course, I could be wrong.
Got some URLs which I'm testing using the requests library. Example code can be found below:
page = requests.get(url)
print (page.status_code)
#output: 200
Some URLs returns a 404 status code when tested manually. Why is the output giving 200 then?
The programmer can define the status code manually. And it may have misled you.
the HTTP status code “200”, means is “file found.” if you redirect to another page, you will get 200 status code
So You do not let your request redirects.
r = requests.get('http://example.com/sdfsdfs', allow_redirects=False)
print(r.status_code)
I am using ServiceStack with MVC4 and getting 500 error when request parameters are long. I am posting ProductIds seperated by commas to controller via AJAX. In controller I have following call to servicestack API to retrieve data.
ResponseDTO res = restClient.Get(new RequestDTO { ProductIDs = ids});
//ResponseDTO res = restClient.Get(new RequestDTO { ProductIDs = "1234,1235,1236"});
If i submit small parameters in above, it works fine with no error. But when parameter string is in range of 1800 characters, it simply fails on above line and gives 500 Internal Server Error:
NetworkError: 500 Internal Server Error - http://localhost/Products/GetProducts
Exception Details: ServiceStack.ServiceClient.Web.WebServiceException: Not Found
is there a limit on GET method for posting large parameter request? Why does it fail for large request when for small parameters it successfully calls API, retrieves data via SQL procedure and sends to view correctly. What can I look into to solve this? Thank you!
p.s. when i debug via VS2012, i see exception details I see Message:Not Found and StatusCode: 404.
As Scott mentioned above, we tried POST for all methods and it fixed issue. I knew GET had limit on browser URL length but didnt think it matters as we had ServiceStack framework and all of their examples were using GET. Thanks again Scott.
I've been working with the grails plugin: 'grails-rest-client-builder:2.0.1'
https://github.com/grails-plugins/grails-rest-client-builder/
I'm experiencing an odd issue when I POST some data to a web service, a 500 Exception, even though the POST indeed is working successfully.
Class
java.lang.NoClassDefFoundError
Message
org/springframework/util/StreamUtils
Around line 195 of PageFragmentCachingFilter.java
if (CollectionUtils.isEmpty(cacheOperations)) {
log.debug("No cacheable annotation found for {}:{} {}"
new Object[] { request.getMethod(), request.getRequestURI(), getContext() });
chain.doFilter(request, response);
return;
}
The response that is coming back from the web service should look like this:
{"id":"9999","key":"IX-2247","self":"https://jira.xxxx.com/rest/api/latest/issue/9999"}
Again, the web service is correctly getting the values that I pass into it, and I verified this by checking the application that I'm posting to and I do see what I expect. Not only that, but I also receive an email from the system that I am POSTing to, and the email contains the correct values from the Grails application.
Here's the POST that I'm using:
def rest = new grails.plugins.rest.client.RestBuilder()
def resp = rest.post("https://jira.xxxx.com/rest/api/latest/issue/"){
auth "Basic xxxx"
contentType "application/json"
json builder.toPrettyString()
}
My hypothesis is that perhaps the issue is that the rest-client-builder is having some kind of issue with the response that is being returned from the web service.
Has anyone encountered anything like this before, where the service is working, but Grails throws a 500 error, even on a successful POST?
Please let me know if I need to provide additional information.
Thanks in advance!
Thank you all for the replies. I ended up upgrading my Grails application to 2.3.5, from 2.2.3 and now the code (above) works perfectly. The 500 error disappeared completely.
I am using the Thinktecture.IdentityModel 4.0 samples for WebApiSecurity. I've modified the AdfsSamlClient to use our ADFS Server. I am able to get a SAML token from out ADFS Server using
var channel = factory.CreateChannel();
var token = channel.Issue(rst) as GenericXmlSecurityToken;
Then I try to make the service call
var client = new HttpClient { BaseAddress = _baseAddress };
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("AdfsSaml", saml);
var response = client.GetAsync("identity").Result;
And get a 401 - Not Authorized call.
I am not sure how to debug this. I have tracing for Microsoft.IdentityModel, but it is only information level trace, no errors or warnings, and nothing I am able to use to debug.
The interesting part of the service trace:
1.
Description OnEndRequest is redirection to IdentityProvider '/WebHost/api/identity'
2.
Description CreateSignInRequest
BaseUri https://[ADFS...]/adfs/ls/
wa wsignin1.0
wtrealm https://[WorkStation...]/WebHost/
wctx rm=0&id=passive&ru=%2fWebHost%2fapi%2fidentity
3.
Description Redirecting to IdentityProvider: 'https://[ADFS...]/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2f[WorkStation...]%2fWebHost%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fWebHost%252fapi%252fidentity&wct=2013-09-30T17%3a35%3a04Z'
Thanks for any insight.
Main thing that springs to mind is to make sure the server knows how to handle the "AdfsSaml" scheme that you're using, so you'll want to make sure that your mapping is correct to your token handler.
One thing I tried was to create my own token handler, and mapped that as the token handler for the header. If you want, you can start with Thinktecture's own HttpSamlSecurityTokenHandler, and debug your way through that. Obviously, if it never hits it, then you've got a mapping issue somewhere.
I also found that if an exception was thrown in the ClaimsAuthenticationManager, it would report as unauthorized - even though the exception being thrown was something completely unrelated (in my case, an InvalidCastException). That stumped me for a while, because I hadn't realise that authentication had gotten so far down the pipeline and that validation of the token had actually been successful - I was just checking the HTTP response, which kept saying unauthorised - so make sure you're not being misled by anything trivial like that.