al03 / cocoa-rest-client

Automatically exported from code.google.com/p/cocoa-rest-client
Other
0 stars 0 forks source link

Problem with encoding of + #35

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
If i have the following scenarios of input/output from my application when 
posting the data with cocoarestclient. Im trying to post the data +46.8

input (raw input checked): phonenumber=%2B46.8
output: +46.8
In this case everything is looking fine. I have encoded the data and posted is 
decoded in the backend.

input (not raw input, the input with the fields/rows): 
param key: phonenumber
paramvalue: %2B46.8
output: %2B46.8
This is expected if the cocoarestclient should encode the data. It simply gets 
doubleencoded.

If i stop encoding the data myself however, i see this:
input(raw input): phonenumber=+46.8
output: 46.8
The plus is interpreted as an space by my application. Arguably bad but 
expected.

input(not raw): 
param key: phonenumber
paramvalue: +46.8
output: 46.8
This i did not expect. If %2B46.8 got encoded a second time, why didn't + get 
automatically encoded?

What is the expected output? What do you see instead?
In the last example i would expect to see the output +46.8. I would expect 
%2B46.8 in raw input mode be the same as +46.8 in "none raw input mode".

What version of the product are you using? On what operating system?
1.3.5 on osx 10.8.4

Please provide any additional information below.

Original issue reported on code.google.com by nassoZe...@gmail.com on 24 Jun 2013 at 8:22

GoogleCodeExporter commented 8 years ago
Sorry. This might be an duplicate of this:
https://code.google.com/p/cocoa-rest-client/issues/detail?id=32

Original comment by nassoZe...@gmail.com on 24 Jun 2013 at 8:28

GoogleCodeExporter commented 8 years ago
I havn't found any workaround for this. Have been unable to post +, as is 
needed for my testing.

The only way i could work around it was to double encode the string on the 
client side and double decode the string on the serverside. It works as an 
temporary fix while testing/developing.

Original comment by nassoZe...@gmail.com on 25 Jun 2013 at 6:15

GoogleCodeExporter commented 8 years ago
Thanks for the detailed description, I'll dig into this this weekend probably. 

Original comment by mike.mat...@gmail.com on 29 Jun 2013 at 3:40

GoogleCodeExporter commented 8 years ago
Thanks, this will be fixed in the next release. There seems to be a strange 
quirk in the URL encoding method in Cocoa for NSStrings such that "+" and "&" 
are not escaped with %2B and %26, respectively. I'm not sure why. I was already 
fixing the & case, but I have added code to correct the + as well. 

As for the behavior of the raw request block, that is more debatable. I could 
see how it would be a nice convenience to automatically form encode the block, 
however it can get into deepwater quickly. Suppose the user wants to provide 
two parameters:

"phonenumber" with value "+46.8"
"address" with value "First & Market St" 

If the user then just entered the raw body: 

phonenumber=+46.8&address=First & Market St

It's not really clear to the application (without more complex logic) which "&" 
characters need to be encoded and which do not. So, I think because raw has 
always just worked with an "encode it yourself" approach, I will leave that be. 

Original comment by mike.mat...@gmail.com on 29 Jun 2013 at 5:38

GoogleCodeExporter commented 8 years ago

Original comment by mike.mat...@gmail.com on 29 Jun 2013 at 8:34