SOAP requests should state the charset of their payloads

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
15 years ago
a year ago

People

(Reporter: chantepie, Assigned: keeda)

Tracking

({fixed1.7})

Trunk
fixed1.7

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(4 attachments)

(Reporter)

Description

15 years ago
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"
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

15 years ago
Created attachment 149370 [details] [diff] [review]
Possible fix

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

15 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

15 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

15 years ago
Created attachment 149639 [details] [diff] [review]
Updated fix

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

15 years ago
Created attachment 149640 [details] [diff] [review]
diff -w version of the above
(Assignee)

Comment 7

15 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 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+
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

15 years ago
Patch checked in on trunk. As far as branch goes, I guess my earlier version
should do.
(Assignee)

Comment 11

15 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 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

15 years ago
Created attachment 149758 [details]
testcase

Patch seems to work according this testcase.
Read first the 'README' file in the tarball plz.

Comment 14

15 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+
Attachment 149370 [details] [diff] checked in on the 1.7 branch.
Keywords: fixed1.7
(Assignee)

Comment 16

15 years ago
Thanks jst.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Whiteboard: needed-aviary1.0 (?)

Updated

15 years ago
Whiteboard: needed-aviary1.0 (?) → fixed-aviary1.0

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.