ContentType should be Content-type

There was some funny bean parsing going on here. Now fixed: http://fisheye.codehaus.org/changelog/mule/?cs=13442

changing the fix version

I'm not sure this is working very well yet.

– From my config file –

Global settings:
############

<http:connector name="myHTTP-Connector"
enableCookies="true" />

<message-properties-transformer name="delete-content-type-header" >
<delete-message-property key="Content-type" />
</message-properties-transformer>

<message-properties-transformer name="add-xml-content-type-header" >
<add-message-property key="Content-Type"
value="text/xml" />
</message-properties-transformer>

<!--
This transformer removes the "cookies:" header, which eliminates this error message in the logs:
org.apache.commons.httpclient.cookie.CookieSpec: Invalid cookie state: domain not specified
-->
<message-properties-transformer name="delete-cookies" >
<delete-message-property key="cookies" />
</message-properties-transformer>

###########################
The outbound endpoint that works:
###########################

<http://outbound-endpoint connector-ref="myHTTP-Connector"
address="http://my.server:9424"
method="POST"
transformer-refs="myPayload-To-XML delete-content-type-header add-xml-content-type-header delete-cookies"
responseTransformer-refs="parse_HTTP_Response"
remoteSync="true"
remoteSyncTimeout="10000" />

###########################
What the working output looks like:
###########################

$ netcat -l -p 9424
POST / HTTP/1.1
Content-Type: text/xml
X-MULE_CORRELATION_ID: a40fa210-cb90-11dd-bde1-bf0c7a580702
X-MULE_ENCODING: UTF-8
X-MULE_ENDPOINT: http://my.server:9424/
X-MULE_ORIGINATING_ENDPOINT: myServiceName
X-MULE_REMOTE_CLIENT_ADDRESS: /some.ip:54117
X-Cnection: close
http.method: POST
http.request: /
http.version: HTTP/1.1
method: POST
User-Agent: Jakarta Commons-HttpClient/3.1
Host: my.server:9424
Content-Length: 647

<?xml version="1.0" encoding="UTF-8"?> <!-- my xml -->

#################################
The outbound endpoint that doesn't work:
#################################

<http://outbound-endpoint connector-ref="myHTTP-Connector"
address="http://my.server:9424"
method="POST"
contentType="text/xml"
transformer-refs="myPayload-To-XML delete-cookies"
responseTransformer-refs="parse_HTTP_Response"
remoteSync="true"
remoteSyncTimeout="10000" />

###########################
What the broken output looks like:
###########################

$ netcat -l -p 9424
POST / HTTP/1.1
Content-Type: text/xml
Content-type: application/x-www-form-urlencoded
X-MULE_CORRELATION_ID: 459e952a-cb91-11dd-a9f1-cd2b2d1efe63
X-MULE_ENCODING: UTF-8
X-MULE_ENDPOINT: http://my.server:9424/
X-MULE_ORIGINATING_ENDPOINT: myServiceName
X-MULE_REMOTE_CLIENT_ADDRESS: /some.ip:54657
X-Cnection: close
http.method: POST
http.request: /
http.version: HTTP/1.1
method: POST
User-Agent: Jakarta Commons-HttpClient/3.1
Host: my.server:9424
Content-Length: 647

<?xml version="1.0" encoding="UTF-8"?> <!-- my xml -->

##################

As near as I can tell, the only difference between the two is the extra "Content-type" header.
For some reason, this breaks the remote service I'm using. (Which I have no control over nor visibility into.)

Things definitely appear better. The contentType attribute definitely sets a Content-Type header.
However it seems to add or leave an apparently unnecessary header, which is confusing the particular application I'm hitting.

I'll continue to use the header modifying transformers for now and not really worry about it too much. However I wanted to point out that the behaviour isn't exactly what was expected...

Hmm. Thinking about this a little more, Maybe that "Content-type: application---" header is getting set on the message at the INBOUND http endpoint (for my service). The header sticks around after a few transformations and some component processing, and ends up going out with the outbound HTTP endpoint. When I explicitly delete it, all is ok. The outbound endpoint isn't adding any extra headers, it is just passing along what was already there.

Yep, that was it. I installed the delete-content-type-header on my inbound endpoint, and it was no longer there on my outbound-endpoint.

So is that still a bug? Yes, I think so. You really should only have one content-type header. If you explicitly set it on the endpoint, it should wipe out any existing ones.

To follow up further.
Setting the contentType attribute on an https endpoint does not work with this fix.

Using the same example as above...

...except my connector looks like this, and the endpoints are "https":
####################################################

<https:connector name="myHTTPs-Connector"
enableCookies="true" >

<!-- The https connector wants all three of these defined even though we only use this for an outbound endpoint. -->
<https:tls-client path="${client.keystore}"
storePassword="${storepassword}" />

<https:tls-key-store path="${server.keystore}"
keyPassword="${keypassword}"
storePassword="${storepassword}" />

<https:tls-server path="${truststore}"
storePassword="${storepassword}" />

</https:connector>

##############################################
Instead of using netcat, I generated a self-signed certificate:

$ openssl genrsa -out rotten_key.pem 1024
$ openssl req -new -key rotten_key.pem -out my_key.pem
$ openssl x509 -req -in my_key.pem -signkey rotten_key.pem -out rotten_certificate.pem

Then I started an openssl server:

$ openssl s_server -accept 9424 -cert rotten_certificate.pem -key rotten_key.pem

And I grabbed the certificate (from another window) with openssl client:
$ openssl s_client -connect my.server:9424 | openssl x509 > rotten.cer

Then put that in my trusted keystore for my Mule instance:
$ keytool -import -v -alias rotten -keystore my.truststore -storepass my.password -file rotten.cer

Then I connected through my ESB.

1. 1. 1. 1. The configuration that works (manually adding and removing the Content-Type header with transformers) produces this:

----BEGIN SSL SESSION PARAMETERS----
MHUCAQECAgMBBAIABAQg0qW9DZVr469PWTOPSuEP1rsAXGofHNXJ4ZhdTS9FET4E
MIqXRB1K6eHyjE0InqTfZa6FoXcmEKfRWRjSM3jyGHzRRz5btWKBNqGUGU3RwcLc
SqEGAgRJSAjbogQCAgEspAYEBAAAAAE=
----END SSL SESSION PARAMETERS----
Shared ciphers:RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-DSS-AES256-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:EXP-RC4-MD5:EXP-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA
CIPHER is RC4-MD5
POST / HTTP/1.1
Content-Type: text/xml
X-MULE_CORRELATION_ID: 2e864de4-cbac-11dd-a1df-87eb2fd741a9
X-MULE_ENDPOINT: https://my.server:9424
X-MULE_ORIGINATING_ENDPOINT: myServiceName
X-MULE_REMOTE_CLIENT_ADDRESS: /some.ip:55032
X-Cnection: close
contentType: text/xml
http.method: POST
http.request: /
http.version: HTTP/1.1
method: POST
User-Agent: Jakarta Commons-HttpClient/3.1
Host: my.server:9424
Content-Length: 647

<?xml version="1.0" encoding="UTF-8"?><!-- my xml -->

1. 1. 1. 1. The configuration that doesn't work, (using the contentType attribute) produces this:

----BEGIN SSL SESSION PARAMETERS----
MHUCAQECAgMBBAIABAQgtnPBlLWk1oNsDp91DvrmC81qhIJtGTOQTzZcVy5BzW8E
MOIVn9xloc+qK7QkF1uHQDVszpeF0vFSrLePDjs3du3CGhHiv9qYdAbGbOS1X8qD
06EGAgRJSAm4ogQCAgEspAYEBAAAAAE=
----END SSL SESSION PARAMETERS----
Shared ciphers:RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-DSS-AES256-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:EXP-RC4-MD5:EXP-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA
CIPHER is RC4-MD5
POST / HTTP/1.1
X-MULE_CORRELATION_ID: b01f2ef6-cbac-11dd-9218-97c970e406b9
X-MULE_ENDPOINT: https://my.server:9424
X-MULE_ORIGINATING_ENDPOINT: myServiceName
X-MULE_REMOTE_CLIENT_ADDRESS: /some.ip:55668
X-Cnection: close
contentType: text/xml
http.method: POST
http.request: /
http.version: HTTP/1.1
method: POST
User-Agent: Jakarta Commons-HttpClient/3.1
Host: my.server:9424
Content-Length: 647
Content-Type: text/plain; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?><!-- my xml -->

####
Note that in the second, broken output, the Content-Type header is missing.

going to check this out

adding back to bug backlog until confirmed/resolved.