Unable to call API - Invalid Content-Disposition specified

[RetoolPV]

Hi,

It seems that whenever I try to call a Wordpress API via Retool, I seem to be getting an invalid content-disposition specified error. This error is caused by a header that should define the content-disposition, which I actually have configured (see screenshot below)

.

When I make the exact same call via Postman, it seems to be a success, so i'm pretty confident that my API call has been setup properly. Also, this had been working perfectly before (past 6 months), but recently just broke.

Is there someone who would be able to tell me what's going wrong here so that I can get this working ASAP?

Thanks in advance.

[joeBumbaca]

Hey @RetoolPV, can you share the request that is sent? It's in the same tab as the screenshot of the response. Would love to see how that header is being sent. Did some testing and it looks like we should be sending that header along just fine but curious what it looks like for you.
Request in Retool:

Received in endpoint:

[RetoolPV]

Hi @joeBumbaca

Hereby the request; I did remove the body as it just contained a lot of numbers.

{
  "request": {
    "url": "https://www.url.com/wp-json/wp/v2/media",
    "method": "POST",
    "body": {
      "type": "Buffer",
      "data": [
        
      ]
    },
    "headers": {
      "Content-Length": 5782,
      "User-Agent": "Retool/2.0 (+https://docs.tryretool.com/docs/apis)",
      "Content-Type": "application/pdf",
      "Content-Disposition": "attachment; filename=TestSolarPasArtikel.pdf",
      "Authorization": "---sanitized---",
      "ot-baggage-requestId": "undefined",
      "x-datadog-trace-id": "1120213936518136228",
      "x-datadog-parent-id": "3733644229568326668",
      "x-datadog-sampling-priority": "-1",
      "traceparent": "00-00000000000000000f8bcca3de9b01a4-33d091a5251b6c0c-00",
      "tracestate": "dd=s:-1",
      "X-Retool-Forwarded-For": "84.80.67.20"
    }
  },
  "response": {
    "data": {
      "code": "rest_upload_invalid_disposition",
      "message": "Ongeldige Content-Disposition opgegeven. Content-Disposition moet geformatteerd worden als `attachment; filename=\"image.png\"` of iets vergelijkbaars.",
      "data": {
        "status": 400
      }
    },
    "headers": {
      "connection": [
        "Keep-Alive"
      ],
      "keep-alive": [
        "timeout=5, max=100"
      ],
      "x-powered-by": [
        "PHP/8.2.11, PleskLin, PleskLin, PleskLin"
      ],
      "set-cookie": [
        "PHPSESSID=mup5co2nqrfo8m7ba5o6s5c0s3; path=/; secure"
      ],
      "content-type": [
        "application/json; charset=UTF-8"
      ],
      "x-robots-tag": [
        "noindex"
      ],
      "link": [
        "<https://www.solar4all.eu/wp-json/>; rel=\"https://api.w.org/\""
      ],
      "x-content-type-options": [
        "nosniff"
      ],
      "access-control-expose-headers": [
        "X-WP-Total, X-WP-TotalPages, Link"
      ],
      "access-control-allow-headers": [
        "Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type"
      ],
      "allow": [
        "GET, POST"
      ],
      "expires": [
        "Wed, 11 Jan 1984 05:00:00 GMT"
      ],
      "cache-control": [
        "no-cache, must-revalidate, max-age=0, no-store, private"
      ],
      "content-length": [
        "228"
      ],
      "date": [
        "Thu, 19 Oct 2023 06:25:55 GMT"
      ],
      "server": [
        "LiteSpeed"
      ],
      "vary": [
        "Accept-Encoding"
      ],
      "alt-svc": [
        "h3=\":443\"; ma=2592000, h3-29=\":443\"; ma=2592000, h3-Q050=\":443\"; ma=2592000, h3-Q046=\":443\"; ma=2592000, h3-Q043=\":443\"; ma=2592000, quic=\":443\"; ma=2592000; v=\"43,46\""
      ]
    },
    "status": 400,
    "statusText": "Bad Request"
  }
}

[joeBumbaca]

Looks like that header is formatted properly.

I tested this request out on a few versions and the formatting doesn't look to have changed.

Are you able to share what the Postman request looks like, do you notice any differences?

Are you able to see how Wordpress receives the request?

[RetoolPV]

Hi @joeBumbaca ,

Below's a screenshot of the Postman call, as you can see it got a succes with the same headers.

Even after putting the exact same header hardcoded in Retool i'll getting the error. Seems like Retool is probably formatting the header wrong or something?

[joeBumbaca]

Thanks @RetoolPV, are you able to see / contact Wordpress to see how they receive the request?

Tested this on multiple versions and the Content-Disposition header doesn't appear formatted differently on any of them. Using a couple of different endpoint services (Pipedream / Httpbin) to view the received request, that header appears formatted correctly.

I did notice that there is an Accept header that is sent in your Postman request but not in the Retool request.

Can you try adding that and see if the behavior changes?

[RetoolPV]

@joeBumbaca

Below's the request Wordpress is actually receiving.

{
    "accept": "*\/*",
    "accept_encoding": "gzip,deflate",
    "authorization": "Basic ",
    "connection": "keep-alive",
    "content_type": "application\/pdf",
    "content_length": "5782",
    "host": "www.url.com",
    "user_agent": "Retool\/2.0 (+https:\/\/docs.tryretool.com\/docs\/apis)",
    "content_disposition": "\u0000",
    "ot_baggage_requestid": "undefined",
    "x_datadog_trace_id": "5310518062223254296",
    "x_datadog_parent_id": "5697836768067167536",
    "x_datadog_sampling_priority": "-1",
    "traceparent": "00-000000000000000049b2c00a901ce318-4f12c85a24cda530-00",
    "tracestate": "dd=s:-1",
    "x_retool_forwarded_for": ""
}

As you can see the content-disposition seems to be completely different compared to what Retool is logging. See below (both top and bottom are for the same call)

"headers": {
      "Content-Length": 5782,
      "User-Agent": "Retool/2.0 (+https://docs.tryretool.com/docs/apis)",
      "Content-Type": "application/pdf",
      "Content-Disposition": "attachment; filename=TestSolarPasArtikel.pdf",
      "Accept": "*/*",
      "Authorization": "---sanitized---",
      "ot-baggage-requestId": "undefined",
      "x-datadog-trace-id": "5310518062223254296",
      "x-datadog-parent-id": "2409014881066498849",
      "x-datadog-sampling-priority": "-1",
      "traceparent": "00-000000000000000049b2c00a901ce318-216e8a4554993b21-00",
      "tracestate": "dd=s:-1",
      "X-Retool-Forwarded-For": ""
    }

[joeBumbaca]

Yeah, that is strange. Can you duplicate the query and send it to another endpoint (Ie: pipedream / httpbin) and see if the same null value is received? I'm not seeing the value on that header changed in any meaningful way. Also, can you check the request in the network tab? If you select the query and go to the Preview tab you should be able to see the request headers. I've checked on a few versions, and the header seems to be present and accurate.

[RetoolPV]

@joeBumbaca

After testing via Pipedream it seems that whenever I POST the body as binary type it fails and the header isn't sent. When I change the body type to be raw it seems to work fine, so guess it is solved for now. Although it's weird that using binary body type is removing the header so that could be a bug you'd need to investigate.

[joeBumbaca]

Thanks @RetoolPV, glad this is working for you. I'll look into that discrepancy.