Why "Invalid Content Type" - marketo

Trying to update a data field on a lead record in Marketo. Using C#. I send:
{"action":"updateOnly","input":[{"email":"dfranks#gmail.com","leadQuality":"Hot"}]}
And get back:
{"requestId":"d98e#14b2d7dd1f3","success":false,"errors":[{"code":"612","message":"Invalid Content Type"}]}
Why the Invalid Content type message? The field leadQuality is legit. The email address exists. I've tried a number of different fields and always the same message. Access token is good too.

Content-Type is a HTTP header. Usually, you set it to application/json for REST calls.
You should do this in the code where you generate the HTTP request or REST call.
I found text/json as Content-Type and Accept header value in one of the marketo examples. You might try one of the two choices.

Here are a couple of things to check:
As #StephenKing mentioned, I would check that your Content-Type HTTP
Header is set to "application/json".
I would also confirm that the custom field you created for "leadQuality"
has a String data type.

Related

HTTP request header field "optdata"

So, I googled a lot but couldn't find a HTTP request header field called "optdata". I am working on allowing the user to watch DRM protected videos on chromecast device. I am following a document from drmtoday.com which says:
For Widevine, the metadata must be carried inside the “optdata” field,
inside the HTTP request header with name “dt-custom-data” or
“x-dt-custom-data”.
I understand that the header key name is "dt-custom-data" but couldn't find any reference explaining what exactly is optdata.
If I just encode the following data to base64 and pass it as 'dt-custom-data' header, the request fails saying that 'HTTP Status 412 - Precondition failed'.
{
"userId":"12345",
"sessionId":"RWFzdGVyZWdn",
"merchant":"a-merchant"
}
It just means that dt-custom-data and x-dt-custom-data headers support key/value pairs. optdata is a recognised key.
E.g.
dt-custom-data: optdata={ "userId":"12345", "sessionId":"RWFzdGVyZWdn", "merchant":"a-merchant" }

How do HTTP conversations flow?

I know that clients and servers most commonly communicate through HTTP forms. I know enough about the GET methods, but the little I do know about POST methods is that they're used to submit data to the server. However, when the server receives a POST method and processes the data, it sends a status code like 200 etc., but how does the server send more data? I know there's a body but what does it look like? Does it have parameters and values just like a POST method?
The format of the body is specified in the Content-Type header.
A commonly used Content-Type for form data submission is application/x-www-form-urlencoded. The body for such a request should look something like this:
key1=value1&key2=value+with+spaces
Where key1 and key2 are input names and value1 and value+with+spaces are the corresponding values. Note that key names and values are url encoded
Another common type is application/json, which means the request body should be interpreted as JSON data, for example:
{
"key": "value",
"another_key": "value"
}
So it's just data, and the Content-Type header tells the server how to interpret it.
Edit: A good way to see what's going on is create a form with method="post", and analyze the request with your browser developer tools when the form is submitted.

Jmeter 2.9 HTTP Sampler for PUT not passing parameters

I'm using Jmeter version 2.9, HTTP sampler to test my rest services.
The GET and POST are working without any issues, where as PUT is not passing any parameters in the request to the server.
I verified it with view results in tree.
Any reasons on why this is happening and work around this issue?
It worked for me. Based on what I read on internet, there were different solutions suggested:
Changing Content-Encoding to UTF-8
Pass the PUT parameters in the "body data" tab (as opposed to passing them in tabular format in the "Parameters" tab)
Setting Content-Type header to application/json in the HTTP Header Manager
Passing the parameters via a file (even if this were to work, how would you pass dynamic values?)
passing it as POST with a combination of above points.
WHAT WORKED FOR ME is this combination: Set content type to application/json + Pass parameters as "JSON" in the **body data tab (below is an example)
I did not need to specify UTF-8 or anything else.
EXAMPLE JSON PARAMETER BODY:
{"title":"JMeterTitle","preMortar":"JMeterPre","postMortar":"JMeterPost"}
Pass parameters in path field using:
?name=value&name2=value2
and body in Raw Post body.
if it doesn't work report a bug .
Example:
I am using JMeter 2.11 and I had the same problem. I solved in this way:
1) Setting Content-Type header similar to that you are using in your api method(Example: application/json or application/x-www-form-urlencoded etc.) in the HTTP Header Manager.
2)In HTTP Request. Body Data should look like this:
KEY=VALUE&KEY=VLAUE&KEY=VLAUE&KEY=VLAUE.......
First, try see the logs.
Had a similar problem.
I was using wrongly the "Content-enconding" field as it were the HTTP
Content-Type param. They are not related.
If you need to set Content-Type=application/json you have to use a "HTTP Header Manager" config element.
After setting correctly Content-enconding to UTF-8 the put request started to work.
You should add a parameter with an empty name (in the "parameters" tab).
If the problem persists use the result tree view to analyze the request settings.
I'm using JMeter 2.13 and facing with similar problem. This is How I've solved it:
Setting Content-Type header to text/plain in the HTTP Header Manager
Changing Content-Encoding to UTF-8
In the parameters tab, add the params without name and separated with ampersand character (&)
Screenshot JMeter PUT request example
Hope it helps!

Are PUT and POST requests required/expected to have a request body?

I'm writting a RESTful api, and at I'm thinking about the process of a user creating a key. I have the following possibilities:
GET request to /new/<keyname> - although it's very easy I think I won't use this, because I heard GET is for retrieving and/or listing information;
POST request to /<keyname> - This seemed to me easy and simple enough, but does not pass any data in the request body. Can I do it this way ? Is this weird ?
POST request to /keys passing in the request body "keyname=SomeKey" - Is this the correct way ?
I looked at this API from joyent and in all their PUT and POST requests they pass some data in the request body. Is this expected ? Is it really wrong not to require a request body in a PUT and POST request ?
I asked this question on the Http-WG. This was the most precise answer I got http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0276.html
In summary, POST does not require a body. I would expect the same justification can be applied to PUT.
RFC2616 is the base RFC for HTTP 1.1
In the most general form, an HTTP message is this (note the optional body):
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
Reading further gives this:
9.5 POST
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. ...
and
9.6 PUT
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. ...
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
Both POST and PUT include the phrase entity enclosed in the request.
Based on my reading, I believe that a body is desired (a non-normative description, I know) for both POST and PUT.
In the context of REST, POST is create and PUT is update. I can imagine creating an empty object (perhaps a placeholder for future information), but I don't imagine much use of an empty update.
It is not required. You can send a POST/PUT request without a body and instead use query string parameters. But be careful if your parameters contain characters that are not HTTP valid you will have to encode them.
For example if you need to POST 'hello world' to and end point you would have to make it look like this: http://api.com?param=hello%20world
Probably the best way is your third option: POST to /keys with keyname=SomeKey.
Here's why: You may wish to add another function to your API, for example create_new_user. It would then be difficult to tell the difference between a user trying to POST a key called create_new_user and a user trying to use the create_new_user function.
You are correct in saying that you should not be using GET to do this operation as the GET operation "SHOULD NOT have the significance of taking an action
other than retrieval." (RFC 2616).
To answer your question in one line. Yes it is expected to have Body/Content in body, but it is not required(Mandatory).
According to okHttp3 (an HTTP library for android): the following methods need a body: POST, PUT, PATCH, PROPPATCH (WebDAV) and REPORT (source). It even crashes if you try to do a request with the given methods without a body.

Can AS3 set the Accept Header for Flash Player (not AIR)

"Accept" is not listed in the forbidden headers in the documentation here:
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/URLRequestHeader.html
but cant seem to set it in a GET request. Help!
You are allowed to specify the "accept" header, but only on a POST request with one or more variables.
The documentation comments mention this:
For browser-based Flash/AS3 applications, the only way to successfully set
or modify request headers on a URLRequest object is to set its method to
POST as well as send at least one variable of data along with the request
(i.e. with URLVariables). Otherwise the headers will silently remain
unchanged.

Resources