I reckon you're right Nick - I'm reasonably certain that is the problem. We are using a quite old Java content management system at the server end, and I've already found one place where the direct comparison you mentined is made, so I'm guessing there could well be others within the package itself.
There's a bit more here: http://209.85.229.132/search?q=cache:t9DvR4ZnRJ4J:www.experts-exchange.com/Programming/Languages/Scripting/AJAX/Q_24584541.html+Firefox+3+Content-Type+header+charset%3DUTF-8&cd=2&hl=en&ct=clnk&gl=uk&client=firefox-a Cheers, KH On 8 Sep, 12:56, Nick Fitzsimons <n...@nickfitz.co.uk> wrote: > 2009/9/4 RPrager <ryan.pra...@gmail.com>: > > > > > Here is the only difference I found in the Request Headers: > > > FF2: Content-Type application/x-www-form-urlencoded > > > FF3: Content-Type application/x-www-form-urlencoded; charset=UTF-8 > > > Any ideas? > > One definite possibility is that the server-side component is failing > to cope with the (perfectly valid) inclusion of the charset > information in the Content-Type request header. Check with the > developer responsible that he isn't doing something silly like (in > pseudo-code): > > if (Request.ContentType == "application/x-www-form-urlencoded") // > then do the form parsing > > as this would cause the problem you are seeing, and is also a broken > way of parsing a request. > > Regards, > > Nick. > -- > Nick Fitzsimonshttp://www.nickfitz.co.uk/
