POST request to IPFS gateway returns 405

Hello everyone,

I’m developing the service and currently to check writability status I make a POST request to the API add method (:5001/api/v0/add). Seems that only writable gateway is Infura. But it doesn’t, see Seems that there are other nodes that are writable, but it doesn’t expose the API.

For testing, I execute this request curl -v -X POST, but it returns a 405 code:

> POST /ipfs/ HTTP/1.1
> Host:
> User-Agent: curl/7.60.0
> Accept: */*
< HTTP/1.1 405 Method Not Allowed
< Date: Sat, 30 Mar 2019 18:09:44 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 41
< Connection: keep-alive
< Server: nginx
* Connection #0 to host left intact
Method POST not allowed: read only access

This response can be confusing because it says that we can’t POST any request. Should Infura allow this type of requests? Or maybe redirect it to :5001/api/v0/add… I don’t know, some explanation?


Check out the docs here, would appear the structure of your URL in the request is incorrect,

yeah @mike, but seems that the standard method to check writable gateways is send a POST request to the gateway (for example, and if the response is ok, then the node is writable, otherwise, the gateway is not writable.

This is the same behavior for all public IPFS gateways except Infura, that is writable through the API but it doesn’t allow POST request to gateway…

Should Infura change this?? Do you know what I mean? :smile:

This seems like undocumented behavior. Have you found a reference to that behavior in the IPFS API specification? Just to make sure I understand your use case, are you trying to determine which public endpoints allow you to pin content to their node by making a POST request to the IPFS gateway endpoint?

Yes, I want to show public gateways that allow add content. For that purpose, I make a POST request, and gateways that return a 2xx response are writable, otherwise not. Note that these writable gateways do not have to have public the API from the 5001 port (/api/v0/add). For example, don’t expose the API but I can add content:

$ curl -v -F file=@hello.txt

> POST /ipfs/ HTTP/1.1
> Host:
> User-Agent: curl/7.60.0
> Accept: */*
> Content-Length: 191
> Content-Type: multipart/form-data; boundary=------------------------4d9b131b754953e3
< HTTP/1.1 201 Created
< Server: nginx/1.10.2
< Date: Tue, 02 Apr 2019 19:55:20 GMT
< Content-Length: 0
< Connection: keep-alive
< Access-Control-Allow-Headers: X-Requested-With
< Access-Control-Allow-Methods: GET
< Access-Control-Allow-Origin: *
< Ipfs-Hash: QmTub5mwsS4RdPcc2FGthZ4NUjUBzC8phJvvBx9Fmk8hWF
< Location: /ipfs/QmTub5mwsS4RdPcc2FGthZ4NUjUBzC8phJvvBx9Fmk8hWF

I’m correct? For reference see this issue

Sorry, now I understand what you’re referring to. We’ve never enabled the writeable gateway option on our endpoint and would need to take a look at it to determine if its feasible for us to support it right now. I’ve logged it as a feature request with our team but it won’t be something we’d be supporting in the near term. Is there a reason you prefer to use the writeable gateway instead of the api add option?

The only reason to use the writable gateway option is to check if the gateway is writable. Check the service that I developed to view the public IPFS gateways state. Writable gateways are shown in green (W column), but Infura doesn’t. @egalano thanks for the fast responses. :smile: