Why Facebook debugger raise: The crawler accepts deflate and gzip content encodings - animation

Got this warning: Image Unavailable
Provided og:image, https://t44-post-cover.s3.eu-central-1.amazonaws.com/7ou5 could not be downloaded. This can happen due to several different reasons such as your server using unsupported content-encoding. The crawler accepts deflate and gzip content encodings.
If I send a GET to https://t44-post-cover.s3.eu-central-1.amazonaws.com/7ou5 and pass Accept-Encoding: gzip and Content-Encoding: gzip in Postman, I got back the gif, what is then the problem?
Content is less than 8MB, it is 6.23 MB.
Got this error calling crawler from Graph API:
{
"error": {
"message": "Invalid parameter",
"type": "OAuthException",
"code": 100,
"error_subcode": 1611071,
"is_transient": false,
"error_user_title": "URL Follow Failed",
"error_user_msg": "There was an error in fetching the object at URL 'https://tikex-dev.com/kubl/38fn/j1vd/2mi1', or one of the URLs specified via a redirect or the 'og:url' property including one of https://t44-post-cover.s3.eu-central-1.amazonaws.com/7ou5.",
"fbtrace_id": "A4YG8eB4cFHG9acjUaDuCKk"
}
}

I believe this is happening because you are not linking it to a direct file download link with og:image.

Related

The request body must contain the following parameter: 'client_id'

i have a simple spring boot app and i am using these dependencies in my build.gradle.kts for my oauth2 with azure ad:
implementation("org.springframework.boot:spring-boot-starter-oauth2-client:2.4.2")
implementation("com.azure.spring:azure-spring-boot-starter-active-directory:3.9.0")
I have a RestController that literally does not much. What it should do is, when i call localhost:8080/ i want azure ad be called and it should return my access token (not in the controller but at least i don't want to get any errors mentioned in the following sentences.).
#GetMapping("/")
fun helloWorld(): String? {
return "Hello Users!"
}
However, in the network tab of chrome, i see that there are several calls happening against login.microsoftonline.com. I even recieve the code in one of those requests. So looking pretty good so far.
The last call however fails and returns the following error:
[invalid_request] AADSTS900144: The request body must contain the following parameter: 'client_id'. Trace ID: XXXXXX Correlation ID: XXXXXX Timestamp: 2021-09-30 13:15:30Z
I don't get it, because in one of the requests mentioned above, the client_id is included. So it gets correctly loaded out of my application.properties. I ofc also set the tenant_id and the secret in the app.props.
On google i could not find anything useful about that error, so i hope you can help me :)
Thanks in advance!
There are usually two causes for this error.
The parameter: ‘client_id’ is missing from the request, therefore ensure the authentication request includes the required parameter.
If you are hitting the token endpoint (i.e. https://login.microsoftonline.com/common/oauth2/token ), the Content Type is not set correctly. Ensure the content type is 'application/x-www-form-urlencoded' as a header in the request body.
Also check this so reference .
Ok, so here are my two cents.
I am using the VsCode RestClient Extension and I am trying the POST Request as follows.
# This does NOT work
POST https://login.microsoftonline.com/35b02984-c026-40c5-8cb3-2267c184d48a/oauth2/v2.0/token HTTP/1.1
content-type: application/json
{
"grant_type": "client_credentials"
}
I tried tweaking this in every which way, but always got this error message.
The request body must contain the following parameter: 'grant_type'
{
"error": "invalid_request",
"error_description": "AADSTS900144: The request body must contain the following parameter: 'grant_type'.\r\nTrace ID: 71b6d6f5-4d0d-408b-b702-a935ec73f601\r\nCorrelation ID: 4684f398-ef8b-42f3-9016-fdc8458b1730\r\nTimestamp: 2022-09-30 06:36:12Z",
"error_codes": [
900144
],
"timestamp": "2022-09-30 06:36:12Z",
"trace_id": "71b6d6f5-4d0d-408b-b702-a935ec73f601",
"correlation_id": "4684f398-ef8b-42f3-9016-fdc8458b1730",
"error_uri": "https://login.microsoftonline.com/error?code=900144"
}
Finally this SO Question came to the rescue.
So now I modified the request to the following and this works.
POST https://login.microsoftonline.com/35b02984-c026-40c5-8cb3-2267c184d48a/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic trusted:secret
grant_type=client_credentials
&scope=https://graph.microsoft.com/.default
&client_id=e7f0a65e-d4b8-499f-96c9-d92e3df41e14
&client_secret=JUx8Q~xiMv2hb9OVKz8xtc.cCHvqBvcqpH4sKb4K

have error in postman with POST request to elasticsearch

Making first steps in elasticsearch and reading article
https://www.elastic.co/blog/a-practical-introduction-to-elasticsearch
I try to send requests in postman and got error:
"error": "Content-Type header [multipart/form-data; boundary=--------------------------039246746046020007284747] is not supported",
"status": 406
I filled 2 tabs in postman:
https://imgur.com/a/yCxhOJL
https://imgur.com/a/v5VXGdu
Which options did I miss ?
Thanks!
Send the body as raw JSON:
You've chosen form-data which is not supported in ES. It's JSON-in, JSON-out.

What is the "accept" part for?

When connecting to a website using Net::HTTP you can parse the URL and output each of the URL headers by using #.each_header. I understand what the encoding and the user agent and such means, but not what the "accept"=>["*/*"] part is. Is this the accepted payload? Or is it something else?
require 'net/http'
uri = URI('http://www.bible-history.com/subcat.php?id=2')
http://www.bible-history.com/subcat.php?id=2>
http_request = Net::HTTP::Get.new(uri)
http_request.each_header { |header| puts header }
# => {"accept-encoding"=>["gzip;q=1.0,deflate;q=0.6,identity;q=0.3"], "accept"=>["*/*"], "user-agent"=>["Ruby"], "host"=>["www.bible-history.com"]}
From https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3
This field contains a semicolon-separated list of representation schemes ( Content-Type metainformation values) which will be accepted in the response to this request.
Basically, it specifies what kinds of content you can read back. If you write an api client, you may only be interested in application/json, for example (and you couldn't care less about text/html).
In this case, your header would look like this:
Accept: application/json
And the app will know not to send any html your way.
Using the Accept header, the client can specify MIME types they are willing to accept for the requested URL. If the requested resource is e.g. available in multiple representations (e.g an image as PNG, JPG or SVG), the user agent can specify that they want the PNG version only. It is up to the server to honor this request.
In your example, the request header specifies that you are willing to accept any content type.
The header is defined in RFC 2616.

Creating Item, unprocessable entity

I'm trying to use the connect api to create new products. I keep getting the following error.
{ type: 'unprocessable_entity', message: 'Item[name]:name required, max length 255, min length 1; Item[variations]:Must have at least one variation' }
The object I'm passing does have an name and a variation.
{"variations":[{"price_money":{"currency_code":"USD","amount":500},"name":"Small","sku":"TST101"}],"name":"My Test","description":"This is a desc"}
I'm unsure of why this is failing, any help would be great.
I believe this error is occurring because your request does not include a Content-Type: application/json header. I attempted to create an item with the JSON body you list above, and the request succeeded. I then removed the Content-Type: application/json header from my request, and it failed with the same error you encountered.
This is clearly not a helpful error message, given the actual cause. I will work with the Connect API engineering team to improve it.

Example Content-Types for `POST` validation failures?

Suppose an HTTP server responds to a POST with a 400 response code because the request failed validation (e.g. email address not found). If the server wishes to provide more information to the client about the nature of the error, how should this be returned? For each possible content type used in requests, should there ideally be an associated "error" content type?
For example, given the request
POST /users
Content-Type: application/x-myuser
{
"email": "foo#example.com",
"name": "Michael"
}
a response might be
400 Bad Request
Content-Type: application/x-myuser-error
{
"email": "Email address foo#example.com not found"
}
Are there any good examples of "error" content types publicly available?
I don't have any examples, but it's good to always keep these in mind:
Always include a machine-readable error, and generalize as much as possible. A JSON structure like
{"error":"Email address not found!","code":"fielderror","field":"email","reason":"notfound"} (could be simplified to {"error":"...","code":"emailnotfound"})
allows API developers to properly present the error to the user (and act on the error) while it allows you to change the messages without breaking applications. It also really helps with translation of error messages, both on your end and the external developer's end.
A different approach is to simply don't return any body, and use HTTP headers to tell the user agent what went wrong. For example, you could use X-Error and X-Error-Code to show a human readable error, and a machine readable code.
Creating too many content types might be a bad thing. I personally prefer to always use application/json and let the user agent know the status by looking at the HTTP codes: 200, 400, 403, 404, 500, etc.
Definitely don't ever start making combinations of HTTP codes and content types. You don't want your users to have to learn that application/myapp/error means there's an error, UNLESS it's 200 in which case you're in the edit screen, OR when it's 302 it's not actually an error but a redirect. This is why you should probably stick with one content type.
Bottom line: always keep it simple. Make sure that there's one field which you have to look at, not two or three, when detecting a status. Once the user agent has determined the status it could choose to look at some other fields for extra info, but only after it has determined that something went wrong. Including a separate content type probably won't help there.

Resources