Supported HTTP methods for a canister

Developers
1

I have been trying to look up the restrictions for http requests to a canister
All I can see for HTTP methods is that GET and POST requests get the canister

  1. Is that accurate
  2. Is that a result of the HTTP gateway implementation or are there other factors restricting it
2

I think you can support any method, but they all come in as a query and you need to use the upgrade and then they come in as an http-request_upgraded.

3

In my testing:

Local instance:
GET,POST,PUT,DELETE,HEAD - work
PATCH - 405
OPTIONS - doesn’t hit http_request
CORS allows only GET,POST

Mainnet instance:
GET,POST,PUT,PATCH,DELETE,HEAD - work
OPTIONS - doesn’t hit http_request
CORS allows HEAD,GET,POST,PUT,DELETE,PATCH

So I guess its more of an issue with local replica?

4

Interesting. Any difference between pocket-ic and the legacy dfx replica?

5

Just tried --pocketic, im getting the same results

6

The production HTTP gateways use this axum router while dfx uses this one. Using --pocketic has no effect here as this option influences the IC backend (replica vs PocketIC), not the HTTP gateway implementation (this is always provided by PocketIC as the production implementation is not available for local testing).

I can unify the axum routers, but I’d like to ask for your use case so that I can prioritize accordingly.

1 Like
7

I’m just developing an http framework in Motoko and testing out everything that I can do
I would say the biggest issue is just the inconsistency of the PATCH and the CORS allow

What is the reasoning behind the OPTIONS being handled by the http gateway vs letting the canister http_request handle it? I don’t have much expertise around this so I just genuinely dont know what is standard practice/reasons. But I am having an issue with not being able to access the OPTIONS response in this thread CORS Issue: Custom Header Being Blocked by IC Boundary Node which is causing me some issues.

8

@rbirkner Could you please follow up on this question?

9

Hey @gekctek

Sorry for the delayed response here (and on the other thread on the custom CORS headers). The HTTP gateways/BNs handle all pre-flight (OPTIONS) requests. This has mostly two reasons:

  1. Many canisters (e.g., the asset canister) do not handle pre-flight requests.
  2. It improves user experienced latency as the request is replied to immediately.

Until now, we have never really questioned this. However, now there are more and more developers building their own HTTP canisters and encountering this limitation.

We are currently discussing an alternative approach, where, for HTTP requests, the HTTP gateway would not reply directly to a pre-flight request, but would forward it to the canister and only inject its default if the canister fails to handle it (and potentially cache some of that for better user experience). It is on our list, but will take a few weeks until we will get to it.

1 Like
10

That would be great to have. Thank you

11

I’ve merged a PR making the PocketIC HTTP gateway more consistent with the ic-gateway implementation used by production gateways. Please note that it might still take some time until that fix is released in dfx.

1 Like
12

Hey guys,
Is it possible that this update broke something ?
cc : Pocket ic 8 - IncompleteMessage errors using http_request calls - #2 by Gwojda