Hi, Although I'm also not able to reproduce the test failure locally according to the information Andreas has provided it looks quite obvious what is happening.
The Synapse test case assumes that if the original request misses information about the charset encoding to use this will not change on the way. Reading the RFC I'm not clear about the correct behaviour. But if I interpret http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1 correctly, we might want to change the unit test to just check the content-type using startsWith() for the case the charset has not been set explicitly, although I'm not sure if it is the correct behaviour for Axiom to use a hardcoded default of utf-8 for the case a charset encoding is not present. Especially the reason given in the commit message Andreas refers to (preventing an NPE) does not sound to be the correct motivation. What do others thing? Regards, Eric > Ruwan, > > It is not the HTTP transport that is failing on Hudson, it is a unit > test in synapse-extensions, which is broken because of a change in > Axiom done by someone from IBM; see SYNAPSE-590. > > Andreas > > On Sun, Oct 11, 2009 at 18:29, Ruwan Linton <ruwan.lin...@gmail.com> > wrote: > > Oleg, the thing is I am also not seeing a test failure, but Hudson is > > blaming us :-) I was trying to reproduce the error... > ScriptMediatorTests > > are failing to me because I am on JDK-1.6 but not nhttp transport. > > > > Not sure why that is failing on Hudson? :-(, I don't think your changes > > broke any test cases, since the failure on Hudson seems to be there even > > before that commit. > > > > Thanks, > > Ruwan
