http4s returns InternalServerError if an unhandled error happened.
Is it possible to log url of the request when InternalServerError happened?
If yes, what is the best way to do it?
Isn't it doing this right out of the box?
Here's log from g8 template project from quick start guide https://http4s.org/v0.21/
with added route that throws runtime exception:
[ioapp-compute-1] INFO o.h.s.m.Logger - HTTP/1.1 GET /bad_joke Headers(Accept: */*, Cache-Control: no-cache, Host: localhost:8089, Connection: Keep-Alive, User-Agent: Apache-HttpClient/4.5.12 (Java/11.0.8), Accept-Encoding: gzip,deflate) body=""
[ioapp-compute-1] INFO o.h.s.m.Logger - service raised an error: class java.lang.RuntimeException
[ioapp-compute-1] ERROR o.h.s.service-errors - Error servicing request: GET /bad_joke from 127.0.0.1
java.lang.RuntimeException: haha
at pack.H4sRoutes$$anonfun$jokeRoutes$1.applyOrElse(H4sRoutes.scala:19)
at pack.H4sRoutes$$anonfun$jokeRoutes$1.applyOrElse(H4sRoutes.scala:13)
at $anonfun$combineK$1 # org.http4s.syntax.KleisliResponseOps.$anonfun$orNotFound$1(KleisliSyntax.scala:38)
at getOrElse # org.http4s.syntax.KleisliResponseOps.$anonfun$orNotFound$1(KleisliSyntax.scala:38)
at guaranteeCase$extension # org.http4s.server.middleware.RequestLogger$.$anonfun$impl$9(RequestLogger.scala:97)
at map # org.http4s.server.middleware.RequestLogger$.$anonfun$impl$9(RequestLogger.scala:101)
at flatMap # org.http4s.server.middleware.RequestLogger$.$anonfun$impl$7(RequestLogger.scala:82)
at flatMap # org.http4s.server.middleware.ResponseLogger$.$anonfun$impl$7(ResponseLogger.scala:65)
at guaranteeCase$extension # org.http4s.server.middleware.ResponseLogger$.$anonfun$impl$7(ResponseLogger.scala:88)
at main$ # pack.Main$.main(Main.scala:5)
Related
I have seen many posts but none of the solution is helping me. I have a simple get to one of the Amazon new webservices. The client is HttpClient.
When fiddler is on it passes and gets me result. When fiddler is not running it fails. Since it was not failing when fiddler was on, i installed another tool "Http Debugger" to see the failure and i could not make any difference in both the request (The pass and the failure). Bothe of them are given below
Failure Capture:
GET /sellers/v1/marketplaceParticipations HTTP/1.1
Accept: application/json
x-amz-access-token: Atza|IwEBIN3hOVtNi1xM47txtHcqXi5A3C960AypB7pkWYCxEo7lNiL9EFR-1b_EoD6PQ8lzAXgM4zujF0OBv0NS7sYQ9bWqPMDhHFt8kgvdmlmk3==jrinknrO6PYlZgmFLRGn1Hzmvgldmnj4973bjkfnbkldlcvld vc0BmuqKHUreonrWQxFO49u0yoIiNHVzSxHP0Wo4nWKW5pdd5Fj73gYxnZQQeYF5EAy8lKDCLtndTnJCdlrv5Kk8JK8iFD_H7h3FF5H4gNyTx3uIHxMaU8OkLz_IigsCTNQHwljnubhQlR9aK0J6lRbb0QfOQ4BAT_e1GOKDkShu-U5OdchdF5qNUkKU
user-agent: MSolution/1.0.0.0
X-Amz-Date: 20201201T224620Z
Authorization: AWS4-HMAC-SHA256 Credential=AKIA5SU6JNBJKDAQB76813QI6V/20201201/eu-west-1/execute-api/aws4_request, SignedHeaders=accept;host;user-agent;x-amz-access-token;x-amz-date, Signature=71dd12ee0eaf33cd142dwr242424e91cb5c4bfd6fd4f46d929d
Host: sellingpartnerapi-eu.amazon.com
Connection: Keep-Alive
The error is Forbiden (Just this)
The success capture is (Fiddler running):
GET /sellers/v1/marketplaceParticipations HTTP/1.1
Accept: application/json
x-amz-access-token: Atza|IwEBIMfdZDDaca8HrDGIPft-HQs3Vzi75I4Bk9iNKfsHTkfwsfsfcsvcsaP86DqKkoZE37TiDr3XvmD_vdvavcUE9TzdXhf2jjuULL04keBHI_XYrnTnhXaCPE0gUAc8HvIiW7OXSERz_3RlS9R-nu2lTo_jqzaz0mbUaa-evavaVAVLauh2Ue7Io8pE1tThRTcqM60igPcrBViAUptTAsq-IL5ZT7hOfbNJTJ31GeN8e8IzjkWfe9n4l7B799VM1bJnC-D_alZ2J0HHj4cBNjd3RzAEvavav3fGWkW5iH2_MZ3IyaxYnslvSzNH4h8tvay87OywkkxVUKIn
user-agent: MSolution/1.0.0.0
X-Amz-Date: 20201201T224820Z
Authorization: AWS4-HMAC-SHA256 Credential=AKIAYWBDAQ7XYIPQI6V/20201201/eu-west-1/execute-api/aws4_request, SignedHeaders=accept;host;user-agent;x-amz-access-token;x-amz-date, Signature=7e4db1c114219546848eaffnvclknslnlcvs63c9e0af50edc3cdbe7231c9b
Host: sellingpartnerapi-eu.amazon.com
I have used:
ServicePointManager.ServerCertificateValidationCallback +=
(senderSP, certificate, chain, sslPolicyErrors) => true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
Not sure what is causing this but has anyone seen this ?
The same call through "RestSharp" works, but i donot wnat to use rest sharp.
Shankar
I've got a simple class making a HTTP POST request (to a Neo4j server, but that shouldn't matter) using URLSession, and an integration test that tests that it succeeds.
Through Xcode, via the iOS simulator, I can run this test a million times - it succeeds every time.
However, when I run swift test on Ubuntu Linux (I use the docker image provided by IBM) then I very often will get a test failure saying I got a 401 response.
Replicating that via cURL in the container does not fail at all, so I do not believe this to be a problem with my container.
I have added a packet dump (that I inspect via Charles Proxy) where our of 15 test runs, 7 test runs (and thus 7 requests) fail. All of the failed requests complain that no authentication header was supplied. And from the dump, that is correct, the dump does not contain the authentication header for those requests that fail. But why not? In fact, all of the header flags are different: a successful run has these headers:
POST /db/data/cypher HTTP/1.1
Host: 192.168.0.18:7474
Accept-Encoding: deflate, gzip
Authorization: Basic bmVvNGo6c3RhY2swdmVyRmxvdw==
Content-Type: application/json; charset=utf-8
Accept: application/json; charset=utf-8
Connection: keep-alive
User-Agent: urlsessionTestPackageTests.xctest (unknown version) curl/7.35.0
Content-Length: 135
while an unsuccessful one has these:
POST /db/data/cypher HTTP/1.1
Host: 192.168.0.18:7474
Accept: */*
Accept-Encoding: deflate, gzip
Connection: keep-alive
User-Agent: urlsessionTestPackageTests.xctest (unknown version) curl/7.35.0
Content-Length: 135
All the 200 results have the same headers, and all the 401 results have the same headers. Can you see anything in my code that should warrant such a random request?
I'm invoking a REST service from an OSB Proxy Service, which is working fine if the rest service response is a valid response, i.e., there's no errors. However if the rest service replies with an http error code (e.g. 400 Bad Request), I'm not able to capture anything else except the http error code:
$fault variable in OSB:
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-382502</con:errorCode>
<con:reason>
OSB Service Callout action received an error response
</con:reason>
<con:details>
<con1:ErrorResponseDetail xmlns:con1="http://www.bea.com/wli/sb/stages/transform/config">
<con1:http-response-code>400</con1:http-response-code>
</con1:ErrorResponseDetail>
</con:details>
<con:location>
<con:node>PipelinePairNode1</con:node>
<con:pipeline>PipelinePairNode1_request</con:pipeline>
<con:stage>stage1</con:stage>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
But the rest service, is not only replying with 400 Bad Request, but also adding a message:
<Error>
<Message>The message header contains an invalid brand code.</Message>
</Error>
Which I'm not able to process in my proxy service. Does anyone knows if it is possible to access this message details in OSB or is it a limitation?
The rest service is clearly sending the message, because invoking it directly through soap-ui I'll get the following response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 84
Content-Type: application/xml; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 09 Feb 2015 16:15:32 GMT
<Error><Message>The message header contains an invalid brand code.</Message></Error>
Thanks
I've just found out this is an OSB bug, in case of an HTTP Error code 400 being returned, if the http-content is "Application/XML" the message is ignored.
Oracle released a Patch at the end of last month to fix this issue, which I've tested and it works. I can get the message details in the $body variable now.
Patch: 16986497
If I understand your question, you want to get in addition to the http code, the message error?
I think you should use, in your message flow, an errorHandler , so that you can catch the error and do whatever you want with.
The proxy service operation selection algorithm cannot determine the operation name from the request or returns an invalid operation (one which is not in the WSDL or null). Possible reasons include the following:
An error occurs while computing the operation.
The operation selection algorithm returns null.
The operation selection algorithm returns an operation that is not of the of the operations declared by the WSDL.
Source
I am following the quick start guide and I am able to get both the Cobrand and User token's, however when I try to make a POST request to https://rest.developer.yodlee.com/services/srest/restserver/v1.0/jsonsdk/SiteTraversal/searchSite, I receive a 404 doc not found. I am able to use wget to download the file for /authenticate/login as shown below, but wget receives a 404.
zachallett# ~/code/yodlee/sampleapp
$ wget https://rest.developer.yodlee.com/services/srest/restserver/v1.0/jsonsdk/SiteTraversal/searchSite
--2013-12-09 14:48:02-- https://rest.developer.yodlee.com/services/srest/restserver/v1.0/jsonsdk/SiteTraversal/searchSite
Resolving rest.developer.yodlee.com... 216.35.6.163
Connecting to rest.developer.yodlee.com|216.35.6.163|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-12-09 14:48:03 ERROR 404: Not Found.
zachallett# ~/code/yodlee/sampleapp
$ wget https://rest.developer.yodlee.com/services/srest/restserver/v1.0/authenticate/login
--2013-12-09 14:48:16-- https://rest.developer.yodlee.com/services/srest/restserver/v1.0/authenticate/login
Resolving rest.developer.yodlee.com... 216.35.6.163
Connecting to rest.developer.yodlee.com|216.35.6.163|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘login’
[ <=> ] 16 --.-K/s in 0s
2013-12-09 14:48:16 (1.53 MB/s) - ‘login’ saved [16]
I have tried using this from an external REST client and it works.
Here is the request
POST /services/srest/restserver/v1.0/jsonsdk/SiteTraversal/searchSite HTTP/1.1
Host: rest.developer.yodlee.com
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
cobSessionToken=xxxxxxxxxxxxxxxxxxxxxxxx&userSessionToken=xxxxxxxxxxxxxxxxxxxxxxx&siteSearchString=dag
I use net.databinder.dispatch to call a web server with this:
import dispatch._
def request(in: String, address: java.net.URI, headers: Map[String, String]): String = {
val req = url(address.toString) << in <:< headers
val s = Http(req OK as.String)
s()
}
the client defines:
Connection: keep-alive
and the server defines:
Keep-Alive: timeout=120, max=256
If I call the webserver consecutively many times (but not in parallel), I get an error:
Exception in thread "main" java.util.concurrent.ExecutionException: dispatch.StatusCode: Unexpected response status: 500
at com.ning.http.client.providers.netty.NettyResponseFuture.abort(NettyResponseFuture.java:297)
19:32:46.474 [New I/O worker #10] DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider - Unexpected response status: 500
at com.ning.http.client.providers.netty.NettyAsyncHttpProvider.abort(NettyAsyncHttpProvider.java:1326)
dispatch.StatusCode: Unexpected response status: 500
at com.ning.http.client.providers.netty.NettyAsyncHttpProvider.access$700(NettyAsyncHttpProvider.java:137)
This error does not happen with other web servers that close the connection.
What is the problem here?
The webserver?
The client?
Is net.databinder.dispatch really using the keep-alive feature (so, reusing the same socket), or creating a new one each time?
How do I modify the previous example to tell net.databinder.dispatch to use the keep-alive feature?
the version that i am using:
<dependency>
<groupId>net.databinder.dispatch</groupId>
<artifactId>dispatch-core_2.10</artifactId>
<version>0.9.5</version>
</dependency>