All, I've developed some web services that will be in use by both Java and .NET users. Java clients have no problem with the results, but the first .NET developer has reported a problem with the WCF text encoder for .NET that is preventing them from correctly parsing the response. Has anyone encountered this problem and if so, is there a way that I can fix it on my server side so that we can proceed?
If I could change the order of the headers, that would likely be sufficient. Is there a way to do that through configuration changes? Thanks, Jennifer For reference, here's the email from my client: After a bit of research, I have found that the WCF text encoder has a bug in it right now. It does an awkward series of string parsing to determine the content type and character set in the http header. The current logic assumes that the character set will always immediately follow the content type. However, Axis inserts the optional action parameter between content type and character set. On a side note, let me be clear that I am not saying this is a problem with Axis. WCF just doesn't properly implement the W3C RFC in this situation. For example, the following content type header would be successfully parsed: application/soap+xml; charset=utf-8; action="http://myaction"; However, if you swap the order of action and charset, WCF currently can't handle it: application/soap+xml; action="http://myaction";; charset=utf-8 This is apparently a known issue that will be addressed in the next release of WCF. Unfortunately, I obviously need a solution right now. :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
