Section 20.15 of RFC 3261 mentions the Content-Type as:
The Content-Type header field indicates the media type of the
message-body sent to the recipient. The "media-type" element is
defined in [H3.7]. The Content-Type header field MUST be present if
the body is not empty. If the body is empty, and a Content-Type
header field is present, it indicates that the body of the specific
type has zero length (for example, an empty audio file).
The compact form of the header field is c.
Examples:
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
My question: where is charset defined, and are there any predefined values?
All I found in RFC 3261 was in section 25.1 defines the syntactical form (vai ABNF) for Content-Type as:
message-header = (Accept
...
/ Content-Type
...
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
Thx
In SIP, the Content-Type header is defined as a MIME type and as such inherit of MIME character sets handling . So in theory you should pick the registered values on IANA : IANA charsets
The details of registration are defined IANA Charset Registration Procedures RFC
Related
No matter what value I enter as my request's "Content-Type", the outgoing request I send out seems to replace it with "application/x-www-form-urlencoded". The application I'm trying to hit expects "application/json". My code, basically, is below.
{-# LANGUAGE OverloadedStrings #-}
import Network.Wreq
...
submissionResources = ["https://widgets.example.com/v2/widgets/request"]
sendWidgetToEndpoint submissionResources workingToken key widgetArray = do
let opts = defaults & header "Content-Type" .~ ["application/json"]
& header "apikey" .~ [key]
& header "Authorization" .~ [workingToken]
endPointURL = head submissionResources
widgetId = widgetArray !! 0
numberOfWidgets = widgetArray !! 1
widgetText = widgetArray !! 2
submissionResult <- postWith opts endPointURL [ "widgetId" := widgetId
, "numWidgets" := numberOfWidgets
, "widgetText" := widgetText
]
return submissionResult
My problem is that I keep getting back Status {statusCode = 415, statusMessage = "Unsupported Media Type"} from this endpoint, and I'm confident this is because the request I'm sending appears to be overriding "Content-Type" in my header. I have tried using "application/json" and "text/plain" but the response I get back always indicates to me that all the headers I sent over look as expected except for Content-Type which invariably has become "application/x-www-form-urlencoded".
How can I ensure wreq keeps 'Content-Type: application/json' in my requests header?
EDIT: I'm determining what headers were in my original request by what the API server tells me in its response back to me.
The type of the last argument to postWith in your snippet is [FormParam], and that type is what forces the Content-Type to be urlencoded.
To send JSON, send something of type Value or Encoding (from Data.Aeson).
import Data.Aeson (pairs, (.=))
...
-- also remove the "Content-Type" field from opts
submissionResult <- postWith opts endpointURL $ pairs
( "widgetId" .= widgetId <>
"numWidgets" .= numberOfWidgets <>
"widgetText" .= widgetText )
...
The Content-Type is set by the payload you pass to postWith, via the Postable instance. If you want to use yet another Content-Type header, define your own type with a Postable instance where you set an appropriate Content-Type. You can also choose to not set any Content-Type in the Postable instance, so you can set it via the options instead.
Trying to consume Azure media service rest api. (following the tutorial : https://learn.microsoft.com/en-us/azure/media-services/media-services-rest-get-started)
Everything works fine until the point I try to create a Job. Sending the same request as in example (except asset id and token) and getting response :
Parsing request content failed due to: Make sure to only use property names that are defined by the type
Request:
POST https://wamsdubclus001rest-hs.cloudapp.net/api/Jobs HTTP/1.1
Connection: Keep-Alive
Content-Type: application/json
Accept: application/json; odata=verbose
Accept-Charset: UTF-8
Authorization: Bearer token -> here i send real token
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
x-ms-version: 2.11
Content-Length: 458
Host: wamsdubclus001rest-hs.cloudapp.net
{
"Name":"TestJob",
"InputMediaAssets":[
{
"__metadata":{
"uri":"https://wamsdubclus001rest-hs.cloudapp.net/api/Assets('nb%3Acid%3AUUID%3A5168b52a-68ed-4df1-bac8-0648ce734ff6')"
}
}
],
"Tasks":[
{
"Configuration":"Adaptive Streaming",
"MediaProcessorId":"nb:mpid:UUID:ff4df607-d419-42f0-bc17-a481b1331e56",
"TaskBody":"<?xml version=\"1.0\" encoding=\"utf-8\"?><taskBody><inputAsset>JobInputAsset(0)</inputAsset> <outputAsset>JobOutputAsset(0)</outputAsset></taskBody>"
}
]
}
Response:
{
"error":{
"code":"",
"message":{
"lang":"en-US",
"value":"Parsing request content failed due to: Make sure to only use property names that are defined by the type"
}
}
}
It seems to be related with __metadata property. when I follow instruction from here : Creating Job from REST API returns a request property name error, the error changes:
"error":{
"code":"",
"message":{
"lang":"en-US",
"value":"Invalid input asset reference in TaskBody - "
}
}
}
Cant figure out whats wrong, thanks
Let me check on this, but it could be a couple issues that I have run into in the past.
First. Set both the Accept and Content-Type headers to:
"application/json; odata=verbose"
Next, double check that you are actually using the long underscore character on the metadata property. I've had issues where that was sending the wrong underscore character and it didn't match the property name.
Let me know if either of those helps.
It seems the issue was about "Content-Type". As I am using .net Core it was not easy to set the Conent-type as "application/json; odata=verbose".
1) Tried with RestSharp - dosnt support it, it cuts "odata=verbose" part out
2) Tried with Systsem.Net.Http.HttpClient -> Possible but difficult.
To add it as "Accept" :
MediaTypeWithQualityHeaderValue mtqhv;
MediaTypeWithQualityHeaderValue.TryParse("application/json;odata=verbose", out mtqhv);
client.DefaultRequestHeaders.Accept.Add(mtqhv);//ACCEPT header
To add it as "Content-Type" :
request.Content = new StringContent(content,
System.Text.Encoding.UTF8); //CONTENT-TYPE header -> default type will be text/html
request.Content.Headers.Clear(); // need to clear it - it will fail otherwise
request.Content.Headers.TryAddWithoutValidation("Content-Type","application/json;odata=verbose");
I stuck with sending request with Akka HTTP singleRequest(). I'm trying to deal with Stripe API and it requires application/x-www-form-urlencoded content type for the incoming requests.
I tried to use following structure of HTTP request:
val authorization = Authorization(OAuth2BearerToken("some_token"))
Http().singleRequest(HttpRequest(
uri = Uri("https://api.stripe.com/v1/customers"),
method = HttpMethods.POST,
headers = List(authorization),
entity = FormData(Map("email" -> HttpEntity("test_1#email.com"))).toEntity(),
protocol = HttpProtocols.`HTTP/1.1`)
)
But in the Stripe logs I see following in the Parsed Request POST Body section:
(multipart form: 162)
So the question is how to set content type to application/x-www-form-urlencoded?
The problem was related to FormData type. In order to perform application/x-www-form-urlencoded request you need to use FromData from package akka.http.scaladsl.model
So here is working example:
Http().singleRequest(HttpRequest(
uri = Uri("https://api.stripe.com/v1/customers"),
method = HttpMethods.POST,
headers = List(authorization),
entity = akka.http.scaladsl.model.FormData(Map("email" -> "user#email.com")).toEntity(HttpCharsets.`UTF-8`),
protocol = HttpProtocols.`HTTP/1.1`)
)
I am using Akka Http 2.4.1 to post a https request to the twitter api.
According to their documentation, I need two httpheaders. Namely, Authorization and ContentType.
To quote their docs:
The request must include a Content-Type header with the value of application/x-www-form-urlencoded;charset=UTF-8.
Here is my code:
val authorization = Authorization(BasicHttpCredentials(key, secret))
/*
This header is removed from the request with the following explanation!
"Explicitly set HTTP header 'Content-Type: application/x-www-form-urlencoded;' is ignored, illegal RawHeader"
*/
val contentType = RawHeader("Content-Type", "application/x-www-form-urlencoded;charset=UTF-8")
Http().singleRequest(
HttpRequest(
uri = Uri("https://api.twitter.com/oauth2/token"),
method = HttpMethods.POST,
headers = List(authorization, contentType),
entity = HttpEntity(`text/plain(UTF-8)`, "grant_type=client_credentials"),
protocol = HttpProtocols.`HTTP/1.1`))
How can I include the Content-Type header with the value application/x-www-form-urlencoded;charset=UTF-8 using Akka-http 2.4.1?
I think if you change the entity value on your HttpRequest to FormData like so:
HttpRequest(
uri = Uri("https://api.twitter.com/oauth2/token"),
method = HttpMethods.POST,
headers = List(authorization),
entity = FormData("grant_type" -> "client_credentials").toEntity,
protocol = HttpProtocols.`HTTP/1.1`)
)
Then you should get the Content-Type to be automatically set for you to application/x-www-form-urlencoded;charset=UTF-8
Aglio, an API Blueprint renderer, does not allow parameters in the body of a request to be included in the parameters section of the the Endpoint specification. It throws parse warning as follows:
parameter '<some_parameter>' not specified in '<some_description>' its '<some_URI_template>' URI template (warning code 8)
A sample Markdown which would replicate this warning is:
## Journey creation [/v1/journeys/{origin}]
### Create journey [POST]
Create a new journey
+ Parameters
+ origin (required) ... origin location of journey
+ destination (required) ... destination location of journey
+ Request
+ Headers
Accept: application/json
Authorization: Basic <BASIC_AUTH_TOKEN>
+ Body
{
"destination" : "some_other_place"
}
+ Response 200 (application/json)
+ Body
{
"origin" : "some_place",
"destination" : "some_other_place",
"journey_state" : "Not_Started",
"timestamp" : "<dateuuid>",
}
The rendered does not like 'destination' to be a parameter, since it is not in the URI template.
My question is, is this a drawback of the tool, or is it an API Blueprint specificaton? Also, maybe, is this definition of a REST endpoint not per standards?
The correct way to specify message body attributes is using the new MSON attribute syntax, which is used to render JSON and JSON Schema as of Aglio 2.0.
### Create journey [POST]
Create a new journey
+ Parameters
+ origin (required) - origin location of journey
+ Attributes
+ destination: some_other_place (required) - destination location of journey
+ Request
+ Headers
Accept: application/json
Authorization: Basic
In the near future Aglio will render extra information for the attributes.