0

I have a project where we are sending text payloads over HTTP that include special ASCII codes. Using URLEncode on those special ASCII codes works as expected.

The gotcha, is I'm being told to use the x-www-form-urlencoded content type, but to accept the raw body as if it wasn't a form (no key/value pairs) and just urldecode the received content as a single payload.

Question: Is this reasonable? I haven't run across this before and checking on real-world versus potential 'spec-breaking' usage of x-www-form-urlencode (i.e. the 'form' part doesnt matter and can be ignored).

TIA for the cross-check!

dhartford
  • 1,125
  • 2
  • 12
  • 35
  • Can you tell more about how you send this data? Do you use a form or a normal AJAX request? Is the data actually in a key/value format? – R. Q. Mar 09 '16 at 21:40
  • this is headless (REST service like), the data is not key/value format. I'm used to using www-form-urlencoded where the body contains things like data=URLENCODEDDATAHERE file=BASE64 content here where there was always a key=value pairing. – dhartford Mar 09 '16 at 21:48

1 Answers1

1

To answer your question: No, it's not reasonable. If the data is not in key/value format, then using x-www-form-urlencoded as Content-Type doesn't make much sense (see the standard and here is a good explaination).

What to use else? It really depends on your data. From the standard (RFC2045):

Content-Type Header Field

The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.

So if you really have only ASCII characters it is still of type text/something. If the raw data is special to your application you can incen

Community
  • 1
  • 1
R. Q.
  • 904
  • 5
  • 12