Remote wcf service needs a custom header 'MessageHeader' in the envelope. I'm adding this header, but processing response returns this error:
'The header 'MessageHeader' from the namespace
'http://www.ebxml.org/namespaces/messageHeader' was not understood by
the recipient of this message, causing the message to not be
processed. This error typically indicates that the sender of this
message has enabled a communication protocol that the receiver cannot
process. Please ensure that the configuration of the client's binding
is consistent with the service's binding.'
In classic .net recommend change BasicHttpBinding on WsHttpBinding, but core doesn't support it. Can anybody give me some advices?
It appears to be a namespace issue. Please post your RQ + RS and identify what API you are using.
Related
I have a customer that requires us to use a SOAP service (and yes...I tried to have that changed and no go). The soap message needs to look like this with an AuthHeader in the Header.
I've tried using SoapCore with an IMessageInspector2 and a MessageHeader attribute but no luck
Does anyone have a solution for this? I have to send the WSDL to our customer so they can code against it.
I have setup the HttpClient with ServiceUnavailableRetryStrategy. I am making a POST call to the server with JSON payload in InputStreamEntity.
When server returns with "503 Service Unavailable" the retry strategy kicks in and makes another request after a delay read from Retry-After header.
I have enabled the logs and what I observe is, in the first request the JSON payload is sent properly. But on the retry request no payload is sent to the server and I am receiving a "400 Bad Request".
I wonder why the payload is not sent on the retry request. In my implementation of ServiceUnavailableRetryStrategy I am not messing anything with HttpResponse or HttpContext. Is it because that once the content is read from InputStreamEntity, the Entity looses the data?
Is there anyway to prevent this from happening? Any help or suggestions will be appreciated.
thanks
The issue was actually with InputStreamEntity, which is a non-repeatable Entity. This means its content cannot be read more than once. So on retry the original Entity content was lost.
When I use a repeatable Enity like ByteArrayEntity, the issue was solved.
https://hc.apache.org/httpcomponents-client-4.5.x/current/tutorial/html/fundamentals.html#d5e119
In Soap UI REST project, what is the significance or use of adding representations under a method(say POST). I see three types of representations - REQUEST, RESPONSE and FAULT
I think that it's only informative, it shows the different kind of interactions you send/received from the REST service.
You can add new ones manually but I think that this has nonsense because when you invoke the service if your receive a correct response a new entry of kind RESPONSE is added automatically specifying the media-type, http status code and name received from the service.
If instead you receive an error http status like 404, then a new entry of kind FAULT is added specifying also the media-type, http status and name for the fault.
The REQUEST type entry it's only added when you send a REST Request of POST type , if the REST Request is a GET then the entry is not added.
Hope it helps,
I am using mongodb-queue to send the messages. To handle the errors, I'm using the separate channel which send the exceptions. When sending the exceptions, I need to retrieve the POJO.
Please let me know if you have any idea on how to do so.
You generally shouldn't be messing with the error-channel header with a header enricher - that is rarely needed; set an error-channel on the inbound endpoint. The message in the error channel will be an ErrorMessage with failedMessage and cause properties. The failedMessage is the message at the point of failure.
I've been looking at examples of REST API's like Netflix http://developer.netflix.com/docs/REST_API_Reference#0_59705 and Twitter and they seem to place error messages in the statusText header response instead of the responseText. We're developing an internal RESTful api and I am arguing for sending custom statusText messages and ignoring the responseText.
For the scope of our app, we're returning error 400 when the user has tried doing something they aren't supposed to, and the only error messages that will be updated in the UI for the user will be delivered with 400. I am of the belief that the message should be sent as a modified statusText but one of the engineers (who knows a bit less about REST than me) is arguing for sending it in the responseText.
What's the best way to go?
HTTP defines that you should put a descriptive error message in the response entity body, aka responseText.
statusText is not rendered or processed by any client.
I'd use the status text for the error message type, aka 400 Client Error, and the body for a description of the problem that can be rendered to the user, in whatever the format the client may be able to process.
Edit: Note that since then, a new standardised format exists to communicate in a standard fashion error details back to the client, which you can find at https://www.rfc-editor.org/rfc/rfc7807 and which I would recommend.
I think you're right, the general approach is use the existing error mechanism built into HTTP.
In general, try to map your errors to existing HTTP errors, for example if they request something they don't have permission to, return a 403 error.
If they request something that doesn't exist, return a 404.
Alex
According to the HTTP specification (rfc2616): "HTTP status codes are extensible"
However I don't think that creating new statuses for every different error message is the correct approach:
I would say choose HTTP Status appropriately (HTTP Status Code Definitions) if you can't find any category which matches your requirement create a custom one (but I'm sure you will) and put error messages in the HTTP response body.
Picking appropriate status code for your responses is extremely important as it is a key enabler of self-descriptive messages.
The entity body should be a representation of the resource's state and ideally contain hyperlinks to available next states in your application
Http Status Codes are pretty self explanatory and should be used as such. Returning 200 OK with validation errors is pretty Soap-y and misleading. Any REST Client implementation 4xx and 5xx errors go into a error block and it really depends on case to case basis if you really want to use the response body for non 2xx responses.