I’m trying to use the twitter media API to upload an image and i’m struggling to understand how Postman is encoding the variables when using the x-www-form-urlencoded body type.
If i create a variable ‘media=iVBORw0KGgoAAAANSUhEUgAAAAgAAAAIAQMAAAD+wSzIAAAABlBMVEX///+/v7+jQ3Y5AAAADklEQVQI12P4AIX8EAgALgAD/aNpbtEAAAAASUVORK5CYII’ I can generate a 200 response using the x-www-form-urlencoded body
When i put the same body in Raw with a forced x-www-form-urlencoded header I get a 401 Unauthorized (which i think is just a poor error message bubbling up giving my Auth headers aren’t changing.
I presumed this was to do with URLEncoding, so i encoded the value to the below. When i do this in the x-www-form-urlencoded tab i now get a 400 for unsupported media type, and I still get the 401 through the raw body.
Console
When i look into the console for x-www-form-urlencoded I can see the structure it is sending the body in.
However, when i replicate that in raw, i still get a 401 so its doing something different. despite the text being identical, it also looks different in the console, so i’m not sure what i’m doing differently here.
It looks to me like this is being sent as JSON from the screenshots you shared. Judging with the use of the colon after media.
Also, when you say top works, bottom doesnt. o you mean the first Request Body in the below screenshot works? How is it different form the one in the bottom?
It looks to me like this is being sent as JSON from the screenshots you shared. Judging with the use of the colon after media.
Should it not be sent as JSON? Do you have an example of how the data should be structured for x-www-form-urlencoded?
These are the different permutations i can think of, but i’m not sure what is correct here.
“key”:“value”
“key”:value
key:value
key:“value”
“key”=“value”
“key”=value
key=value
key=“value”
Also, when you say top works, bottom doesnt. o you mean the first Request Body in the below screenshot works? How is it different form the one in the bottom?
With regards to the top and bottom screenshots. That was showing how the console looks for the two requests. I was trying to show that when I use the x-www-form-urlencoded body, the console formats the body slightly differently (and the request works), vs when i use the raw body, whilst the data is identical, the formatting is different. This might be a red herring but it was a difference i couldn’t explain.
Request Body
media: “iVBORw0KGgoAAAANSUhEUgAAAAgAAAAIAQMAAAD+wSzIAAAABlBMVEX///+/v7+jQ3Y5AAAADklEQVQI12P4AIX8EAgALgAD/aNpbtEAAAAASUVORK5CYII”
The key difference being the content length. The string is 128, so why does the x-www-form-urlencoded body submit a string of 141.
If i manually set a Content-Length as anything higher than 128 on my raw body request, it hangs and never completes a transaction. If i set it 128 or lower it fails in the same way as previously
What is the difference in how that is calculated compare to the raw body with a Content-Type: x-www-form-urlencoded
It started out as a simple test just to prove i understand how the headers work, and has now turned into a frustrating cycle where on the face of it it should work but it doesn’t. Basically I just want to solve the problem
I’ve made a bit of progress with this using Fiddler. The format of the body is as such;
keyvalue=urlencoded(string)
i.e. media_data=iVBORw0KGgoAAAANSUhEUgAAAAgAAAAIAQMAAAD%2BwSzIAAAABlBMVEX%2F%2F%2F%2B%2Fv7%2BjQ3Y5AAAADklEQVQI12P4AIX8EAgALgAD%2FaNpbtEAAAAASUVORK5CYII
I’ve also managed to get a raw body working with this format, but only when I use the authorisation header generated from the x-www-url-encoded search. When i use the one from the raw body it fails.
So my next question @gbadebo-bello is how does the oauth_signature in the Authorisation header get generated between raw / x-www-url-encoded?
Looks like parameters are included in the oauth_signature generation when using x-www-form-urlencoded, but they are not when using the raw body.
This document pointed me in the right direction. The key bit being the media_data parameter in the body has to be part of the signature generation too.
The encoded parameters i used for the signature are (note alphabetical order)
