I’m trying to set the Content-Type Header to “application/json”. I have added “Content-Type” Parameter under headers section in the HTTP request. But when sending the request UIPath is still sending the Content-Type as :Content-Type: application/x-www-form-urlencoded"
Due to this I’m response from the server is responding with error "“The Content-Type header is missing or invalid”.
I have tried the endpoint with SOAPUI… and it works fine… and I can see the Content-Type is set as “application/json”
If I remember correctly, ‘Content-Type’ header is defined in HttpClient activity by filling non-quoted value (such as application/json) in the BodyFormat field, and you can’t override this using a freely-typed header like you tried. This only applies to GET request made with HttpClient activity, though.
When making a POST request, the BodyFormat field will be ignored and ‘Content-Type’ will always be ‘application/x-www-form-urlencoded’, no matter what. If something else is desired, your best bet is to create a custom activity that utilises .NET code to build a request object from scratch.
EDIT: See my message below for correct information.
Thanks for the input… this is surprising… considering some or most of the REST API Services out there… expect this parameter to be set and validate based on the content they are sending… Is custom activity is the only choice ?
All right, let’s rewind a bit. I had clearly written poorly my old notes regarding HttpClient activity. I just run a few tests and here are the results:
GET request doesn’t, by standard definition, have a message body - it’s reserved only for PUT/POST requests. Instead, GET of course sends any associated data as part of the url, and as such, never needs a Content-Type header anyway. I have a recollection from the past that sending a body in a GET request is technically possible, but then again, it should not be used while GETting stuff done.
Unlike GET, POST request does use body to deliver data, along with the Content-Type header. These can be adjusted to a degree in HttpClient, and here’s how:
If you need Content-Type header application/json or application/xml, place either one (unquoted) into BodyFormat field and fill the stringified request body into Body field.
Request example:
Server-side:
To use application/x-www-form-urlencoded Content-Type, simply fill key-value pairs into Parameters collection.
Note that if you’ve added at least one key-value pair into Parameters collection, everything typed into Body field will be overridden by Parameters and Content-Type will be forced to application/x-www-form-urlencoded.
As a final note, you can’t have the HttpClient activity recognize any Content-Type header via Headers collection, so you’ll always want to stick with using BodyFormat field (except for when using Parameters). Out of content types other than those mentioned here, at least text/plain will get recognized as well. I suppose other ones should work as well.
after little more work… when I add even one “parameter” it’s making the content-type to application/x-www-form-urlencoded which I think it’s wrong… as the parameters are passed in the URL while posting… this should not impact the setting in the “BodyFormat”
@tkein Thanks for that detailed explanation. After filling in the key value pairs into Parameters collection for a PUT request, I am getting the below error. This seems to be a content type issue, but from my understanding the default content type is: application/x-www-form-urlencoded. I don’t have it defined the header nor do I have it in the BodyFormat. In fact, my BodyFormat has application/xml by default. If I remove it or replace it with application/x-www-form-urlencoded, I get the same error:
{
“correlationId”: “f176d0b0-8406-11ee-b59e-16b1e65840e1”,
“errorType”: “APIKIT:UNSUPPORTED_MEDIA_TYPE”,
“errorMessage”: “Unsupported media type”,
“errorDescription”: “Unsupported mediaType”
}