Welcome Guest ( Log In | Register )


 
Reply to this topicNew Topic
HTTP 500 error with Webservice call
jdeleng
post Mar 20 2009, 12:08 PM
Post #1


Visitor
*

Group: Members
Posts: 2
Joined: 20-March 09
Member No.: 419


I have a partner which supplies a webservice to me.
I have added this webservice as default delivery exchange and set the authentication certificate.
When i deliver a soap message to their webservice i'm getting a negative response from their webserver.
When i call the same webservice using SoapUI with the same message i receive the expected answer.
I think their is a technical mismatch between Axway and their webserver (Apache). Maybe charachter-encoding related? I'm trying to solve the problems with the partner, but no luck so far.

Maybe someone recognize the returned response and give me directions?

The response of the webservice is:

CODE
HTTP/1.1 500 Internal Server Error
Date: Fri, 13 Mar 2009 14:09:59 GMT
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Connection: close

<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"><faultcode>S:Client</faultcode><faultstring>Couldn't create SOAP message due to exception: XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'y' (code 121) in prolog; expected '&lt;'
at [row,col {unknown-source}]: [1,1]</faultstring></S:Fault></S:Body></S:Envelope>



Thanks in advance.
Go to the top of the page
 
+Quote Post
Litty Joseph
post Mar 23 2009, 07:23 PM
Post #2


Visitor
*

Group: Members
Posts: 4
Joined: 18-November 08
Member No.: 193


QUOTE (jdeleng @ Mar 20 2009, 01:08 PM) *
CODE
Unexpected character 'y' (code 121) in prolog; expected '&lt;'


Receiver of your SOAP/XML file expect the file to begin with character '<' (that is '&lt;'). But your XML file had a 'y'.
First couple of lines (prolog) in your XML file (such as SOAP message) might be a bit messed up.

Check if HTTP header fields are getting included into HTTP body. Http body should just contain then SOAP part.
Also check if DOCTYPE line is included in the SOAP message.

Go to the top of the page
 
+Quote Post
jdeleng
post Mar 26 2009, 08:22 PM
Post #3


Visitor
*

Group: Members
Posts: 2
Joined: 20-March 09
Member No.: 419


Hello Little Joseph, thanks for your reply.

I've been investigating the problem with the supplier of the webservice.
A monitor-tool tells them, they are receiving only a (the last) part of the soap-body.
The xml-reader responds with an exception that the soap-body is not correct XML, corresponding with my first question.

So, they are receiving only the last part of the xml message, so it seems Axway is splitting the message in parts. (that sounds normal to me)
When the soap-body is downsized to 465 bytes or less, there is a succesfull connection.
In SoapUI large messages/soap-body's where accepted without any problem.
I tought it was a problem of the combination of Axway and the supplier's webserver (Apache), because SoapUI was doing just fine.

Recently i discovered that the problem also occurred with SoapUI, but only with very large messages.
So now i keep the supplier responsible for solving this problem. It could be Apache of maybe a load-balancer. (Just thougths of me, i will communicate with the supplier tommorow)

But in the mean-time is still have the problem, so my new question is:
Is it possible to set the trigger of splitting http-messages in Axway on a larger level?
For example: if Axway will begin splitting http-messages just at 3500 bytes instead of 465, i could continue working without having to wait for the supplier.

Also, if you have any ideas of why the apache webserver is just receiving the last part, it would be appriciated.
Or is it just something else and am i thinking about the wrong reasons for the problem?

(excuse me for the bad English)
Go to the top of the page
 
+Quote Post
Celestemmcknight
post Jun 7 2009, 07:40 AM
Post #4


Visitor
*

Group: Members
Posts: 2
Joined: 4-June 09
Member No.: 552


I guess it would be a bot that is trying to do something it isnt allowed to If it were someone being denied access, they would get a 403 error

Mickey, I see you have been getting them At least the logs say you have
Go to the top of the page
 
+Quote Post

Reply to this topicNew Topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 

Skin designed by IPB Forum Skins