| Author |
Message
|
| pottas |
 Posted: Tue Feb 16, 2016 4:13 am Post subject: HTTP Error 415 afer fixpack upgrade |
 |
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Guys,
We have upgraded a fixpack in our environment, details: below
current version:
BIP8996I: Version: 9005
BIP8997I: Product: IBM Integration Bus
BIP8998I: CMVC Level: S900-FP05
BIP8999I: Build Type: Production, 64 bit, rios_aix_4
But now we get an error calling a web service that we didn't get prior to the fixpack update:
| Quote: |
| Error : 3691; Text : SyncRequest HTTP Error returned : HTTP/1.1 415 Cannot process the message because the content type 'text/xml; charset=iso-8859-1' was not the expected type 'text/xml; charset=utf-8'. |
Do any of you have an idea why, and even better how do we fix it?
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Feb 16, 2016 5:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sent the content in CCSID 1208. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| pottas |
| Posted: Tue Feb 16, 2016 5:23 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Thanks fjb, I will try that.
Further to my investigation, I traced what they send back to us on the Soap layer:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=iso-8859-1
Content-Length: 2827
Date: Tue, 16 Feb 2016 12:46:02 GMT
And it seems the iso comes from their server response, which makes me think that they must actually fix something? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 16, 2016 5:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| pottas wrote: |
Thanks fjb, I will try that.
Further to my investigation, I traced what they send back to us on the Soap layer:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=iso-8859-1
Content-Length: 2827
Date: Tue, 16 Feb 2016 12:46:02 GMT
And it seems the iso comes from their server response, which makes me think that they must actually fix something? |
What's the charset you are sending the message with?
Looks like their answer is using ISO-8859-1...
Maybe if you sent them the message using ISO-8859-1 instead of UTF-8 you would not see this error? Worth a try
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| pottas |
| Posted: Tue Feb 16, 2016 6:44 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
Ok, so I did something weird and, unexpectedly - to my surprise - it fixed the issue.
I defaulted the MQMD and the properties to 'null' before I do the call to the web service:
SET OutputRoot.MQMD = null;
SET OutputRoot.Properties = null;
and viola, i got a response from the service.
But I suspect that is not the root cause of the issue, as it was something that worked for ages before the fixpack.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 16, 2016 7:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I expect the MQMD might have had something to do with it.
I am always uncomfortable removing the properties as they allow you to specify ccsid and encoding...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| maurito |
| Posted: Wed Feb 17, 2016 1:09 am Post subject: |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
You probably need to set
| Code: |
| OutputRoot.Properties.CodedCharSetId |
to the correct value, probably 1208.
| Quote: |
But I suspect that is not the root cause of the issue, as it was something that worked for ages before the fixpack.
|
It could be that the fix pack fixed a related problem and you code was only working by 'fluke' |
|
| Back to top |
|
|
| pottas |
| Posted: Wed Feb 17, 2016 1:25 am Post subject: |
|
|
Disciple
Joined: 27 Oct 2005
Posts: 185
Location: South Africa
|
thanks maurito and fjb,
Yes, i guess the below holds some truth:
| Quote: |
| It could be that the fix pack fixed a related problem and you code was only working by 'fluke' |
So the fixpack exposed something that was 'bad' practice all along.
But here's my problem: implemented source that has been running for years without a problem gets exposed by a fixpack is not doing us any favours.
So by me clearing the MQMD and the Properties was a desperate attempt to 'fix' our problem.
Now that I have time, I will start looking for an alternative to set the properties to proper values again. This to get to a more permanent solution. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Feb 17, 2016 1:58 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| pottas wrote: |
So by me clearing the MQMD and the Properties was a desperate attempt to 'fix' our problem.
|
The old rule, 'What can go wrong will go wrong' has bit you here.
Assuming that all non MQ nodes will play nicely when working on a message tree that includes an MQMD (or vice versa) is something that has been possible ever since the product was expanded past its original (pretty well) MQ Only roots.
Yes it mght have been working for years. possibly more by luck than judgement.
This is why when I develop flows that mix protocols I always stick a trace node before say, a TCPIP Output Node to make sure that the ${Root} and ${LocalEnvironment} trees are as I'd expect them to be.
It also helps solve the problem of getting things in the wrong order which can happen to anyone even, the most expereinced of us from time to time.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
