Closed
Bug 244717
Opened 20 years ago
Closed 20 years ago
SOAP requests should state the charset of their payloads
Categories
(Core Graveyard :: Web Services, defect)
Core Graveyard
Web Services
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: chantepie, Assigned: keeda)
Details
(Keywords: fixed1.7, Whiteboard: fixed-aviary1.0)
Attachments
(4 files)
2.79 KB,
patch
|
jst
:
review+
jst
:
superreview+
asa
:
approval1.7+
|
Details | Diff | Splinter Review |
10.92 KB,
patch
|
Details | Diff | Splinter Review | |
9.92 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
2.93 KB,
application/gzip
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 It's seems I've some encoding trouble with webservice. In the js I've a string with value "Nouveau répertoire", this string is passed to a webservice and in the webservice I get the string value "Nouveau répertoire". In the js the string value is get from a message bundle encoded in UTF-8, and the SOAP response is too in UTF-8 (Apache SOAP) Reproducible: Always Steps to Reproduce: 1. Make string with accent in JS, display it for debug 2. Send the string param to a webservice operation 3. Display received string param in webservice Actual Results: JS displays "Nouveau répertoire" Webservice displays "Nouveau répertoire" Expected Results: Webservice would display the unchanged string "Nouveau répertoire"
Comment 1•20 years ago
|
||
Um... that string your webservice displays is precisely what you get if you take the UTF-8 encoding of your original string and decode it as ISO-8859-1. So the webservice is somehow screwing up its character encodings, sounds like.
Assignee | ||
Comment 2•20 years ago
|
||
The idea is to explicitly state that we are sending utf8. I use this since it fixed some similar issues with .Net webservices for me. I have no idea if it will help Apache SOAP services.
Assignee | ||
Comment 3•20 years ago
|
||
Cédric,it would be great if you could build with the above patch and test and let me know if it helps. If it doesn't, then we probably need a publicly accessible testcase or something to help us figure out what is going on.
Assignee | ||
Comment 4•20 years ago
|
||
I have no way of knowing for certain what the problem with Apache SOAP is, but I can confirm that something similar happens with .Net webservices. Confirming and changing summary to the known part of the problem. Lets fix that first and then see if anything else remains to be done.
Assignee: web-services → keeda
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Summary: Webservice string param encoding → SOAP requests should state the charset of their payloads
Assignee | ||
Comment 5•20 years ago
|
||
In principle this is the same as attachment 149370 [details] [diff] [review]. But I couldn't resist some cleanup and factoring out of duplicated code.
Attachment #149370 -
Attachment is obsolete: true
Assignee | ||
Comment 6•20 years ago
|
||
Assignee | ||
Comment 7•20 years ago
|
||
Comment on attachment 149640 [details] [diff] [review] diff -w version of the above jst, would you please review. The basic idea is to send the charset with the contenttype. This fixes some issues I have seen with sending strings to .Net webservices. And it also is in line with what a lot of SOAP clients seem to do (based on wire dumps I could find amongst the SOAPbuilders interop results at http://www.whitemesa.com/interop.htm ). The rest of the patch is just refactoring some duplicated code.
Attachment #149640 -
Flags: review?(jst)
Comment 8•20 years ago
|
||
Comment on attachment 149640 [details] [diff] [review] diff -w version of the above Looks good, r+sr=jst
Attachment #149640 -
Flags: superreview+
Attachment #149640 -
Flags: review?(jst)
Attachment #149640 -
Flags: review+
Comment 9•20 years ago
|
||
Harshal, would you be able to attach a patch w/o the cleanup of the duplicated code too? We could try to get that in for 1.7 since it seems like this would be a big step forward for our webservices support.
Assignee | ||
Comment 10•20 years ago
|
||
Patch checked in on trunk. As far as branch goes, I guess my earlier version should do.
Assignee | ||
Comment 11•20 years ago
|
||
Comment on attachment 149370 [details] [diff] [review] Possible fix requesting review for branch version.
Attachment #149370 -
Attachment is obsolete: false
Attachment #149370 -
Flags: review?(jst)
Comment 12•20 years ago
|
||
Comment on attachment 149370 [details] [diff] [review] Possible fix Yeah, this would do it for the branch. r+sr=jst
Attachment #149370 -
Flags: superreview+
Attachment #149370 -
Flags: review?(jst)
Attachment #149370 -
Flags: review+
Attachment #149370 -
Flags: approval1.7?
Reporter | ||
Comment 13•20 years ago
|
||
Patch seems to work according this testcase. Read first the 'README' file in the tarball plz.
Comment 14•20 years ago
|
||
Comment on attachment 149370 [details] [diff] [review] Possible fix a=asa (on behalf of drivers) for checkin to Mozilla 1.7. We're wrapping things up and so this will need to land today if it's going to make the release.
Attachment #149370 -
Flags: approval1.7? → approval1.7+
Comment 15•20 years ago
|
||
Attachment 149370 [details] [diff] checked in on the 1.7 branch.
Keywords: fixed1.7
Assignee | ||
Comment 16•20 years ago
|
||
Thanks jst.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Whiteboard: needed-aviary1.0 (?)
Updated•20 years ago
|
Whiteboard: needed-aviary1.0 (?) → fixed-aviary1.0
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•