invalid http response: HTTP/1.1 200

[Former Member]

Hi gurus!

I have a problem with an asynchronous interface.

We are calling a Webservice which we don't need any response. In sxmb_moni it's OK, but in our RWB we see it as failed, with this entry: invalid http response: HTTP/1.1 200.

I have search in logs, and in defaultTrace_00.0.trc we can see the following entry:

Marked transaction for rollback for meesage 4b4ed19f-bbe6-0062-e100-8000ac1f041d(INBOUND). Reason: java.io.IOException: invalid http response: HTTP/1.1 200

We have captured the HTTP header response, and is:

HTTP/1.1 200
Date: Thu, 14 Jan 2010 10:26:03 CET
Server: Mule/1.2
Connection: close
Expires: Thu, 14 Jan 2010 10:26:03 CET
Content-Type: text/xml
Content-Length: 508
X-MULE_CORRELATION_ID: d595447a-00ee-11df-a6a5-becd407b7daa
X-MULE_CORRELATION_GROUP_SIZE: 3
X-MULE_CORRELATION_SEQUENCE: -1

Could it be problem of the X-MULE_CORRELATION headers? Or Maybe PI needs an HTTP/1.1 200 OK?

Thak you!!!!

[Former Member · Accepted solution]

Hi Russell!

I have the .class file modified. But I don't know in which jar file i have to modify it.

Is in the server/mule/mule-1.2.jar??

Thank you!

Ignasi

[Former Member · Accepted solution]

Hi Ignasi,

Applications will typically provide a means for you to apply a patch. On my standard Mule 1.2 install I just put the modified class into a jar file all by itself and then dropped the jar file into the mule-1.2/lib/patch directory. I assume the Mirth system has something similar, but I don't know. Perhaps you can find instructions for a patch unrelated to the issue you have and follow the same process.

Alternatively, you will need to find the Mirth jar file which contains com.webreach.mirth.server.mule.providers.http.transformers.UMOMessageToHttpResponse and then replace the class inside this jar file with your new one.

-Russ

[Former Member · Accepted solution]

Hii

finally I have found the jar containing the class com.webreach.mirth.server.mule.providers.http.transformers.UMOMessageToHttpRespons and have replaced with the new class with the changes (I also make the class constructing a file in order to see if the class where executed) and there was any change, I am not receiving the Ok yet.

[Former Member]

Hi Ignasi,

I think it could be failing due to the missing "Reason Phrase" in the status line (missing the "OK"). I don't think the reason phrase is optional.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP/1.1 200 OK

Thanks,

-Russ

[Former Member]

Hi Russell,

I have send an e-mail to 3rd party to see if they can change it on their Mirth system.

thank you!

Ignasi

[Former Member]

Hi!

they can't change it. Is there any way to force SOAP adapter to accept it?

As it said on the web you have posted: The client is not required to examine or display the Reason- Phrase.

Maybe modifying the XISOAPAdapterBean in the communictaions channel??

Thank you!!

[Former Member]

Hi Ignasi,

I personally donu2019t think you will have much luck getting XI to accept this response since itu2019s not an XI issue. Itu2019s true that the client (XI in this case) is not required to examine or display the reason-phrase, but that statement doesnu2019t negate the requirement on the server to provide it. The client has the option to look at it or not, but the server must still provide it either way.

I didn't notice the http header before, but the server you are connecting to is actually Mule version 1.2. This release dates back to 2005. I ran a quick test and reproduced the issue using Mule 1.2 (hello-http sample). This may not be the same exact issue, but I did observe the same issue with the missing reason-phrase. The issue is fixed in the Mule 1.3 release.

Perhaps they can request a patch for 1.2. This may not be possible since they are working on the Mule 3.0 version now, but I really donu2019t know. Itu2019s literally one line of code. I made one small change and was able to get the hello-http sample working (code is open source):

Class: org.mule.providers.http.transformers.UMOMessageToHttpResponse

From this:

httpMessage.append(status).append(HttpConstants.CRLF);

To this:

httpMessage.append(status).append(" ").append(org.apache.commons.httpclient.HttpStatus.getStatusText(status)).append(HttpConstants.CRLF);

org.apache.commons.httpclient.HttpStatus.getStatusText is the method they are using in 1.3 to resolve the reason-phrase using the status code.

Thanks,

-Russ

[Former Member]

Wooow! Great response!

I am trying to find where the java code of the claas is, but i haven't find it. I have seen on mirth web there are several java's, but all modified by other peopole. I would like to change it from the original java, since Mirth is not the system we manage.

Thank you!!!!!!!

PD: I have copied the code of the class with netweaver developer studio, but when I copy the code and imported the mule-1.2.jar I can't compile that code. It gives me several errors at compiling, for exemple on line

connector.isResponseFromTransformer()

It tells me the method is undefined.

Any idea, how have you modified the class?

Edited by: Ignasi Pujals Palau on Jan 21, 2010 4:51 PM

[Former Member]

Hi Ignasi,

Please note that Iu2019m not familiar with Mirth at all. However, I took a quick look at the code trunk and noticed that Mirth copied the original Mule code into their own package and modified it:

Original code package is:

org.mule.providers.http.transformers.UMOMessageToHttpResponse

Looks like the Mirth code package is:

com.webreach.mirth.server.mule.providers.http.transformers.UMOMessageToHttpResponse

This class differs from the original somewhat, but still has the code issue that I pointed out before. So, I assume you are trying to modify com.webreach.mirth.server.mule.providers.http.transformers.UMOMessageToHttpResponse. If so, then I think you need to add the Mirth jar files which contain the following packages to your classpath:

import com.webreach.mirth.model.MessageObject;
import com.webreach.mirth.model.Response;
import com.webreach.mirth.server.mule.providers.http.HttpConnector;

-Russ

[former_member187339]

Hi Ignasi,

If you dont want any response, make sure the sender communication channel have Quality of Service as Exactly Once or Exactly once in Order mode.

But what adapters are you using in sender and receiver side?

Regards

Suraj

[Former Member]

Hi Suraj, thank you for your quick reply.

I have no sender communication, since for sender I am using a proxy. For receiver I am using a SOAP adapter.

R/3 -proxy-> PI -soap-> 3rd party

Thank you!

[former_member187339]

Hi Ignasi,

Make both interfaces (at soap side and Proxy side) as asynchronous and it shoudl work

Regards

Suraj

[Former Member]

Hi Suraj,

both interfaces are already asynchronous.

Yesterday I tried to make both interfaces synchronous, and the same invalid http response message was on sxmb_moni. It looks like the response, but the third-party can't change it.

Regards,

Ignasi

[Former Member]

That's strange though, cuz HTTP/1.x 200 means "OK", so I do not understand why it gets interpreted as an error ... Maybe 1.1 is not supported ? Is there any way to switch / force HTTP/1.0 ?

Rgds

Chris

[Former Member]

Hi PFERTZEL ,

yeah, it is what I don't understand too. That is why I think that the problem might be in the headers, and PI can't understand the message. I have tried to force HTTP1.0 in my communications channel but I don't have seen where I can do it.

Thank you,

Ignasi

[Former Member]

Are you using an HTTP destination (in SM59) ? In the "options" tab, there is a way to specifiy HTTP/1.0 or 1.1 ... Otherwise, I dunno how to set it in the channel definition

Chris

[Former Member]

We have several HTTP destinations, but I am not sure if we are using any of them, couse i don't think we send it via RFC.

Anyway, HTTP1.0 is selected in the most of the destinations.

3rd party have made a test, and these X-MULE_CORRELATIONS headers does not appear. Its so strange...

rgrds

Ignasi