HTTPS Page Rule is breaking POST requests to my API

[NOTE: this has nothing to do with the Cloudflare API–this is about my own API that is secured by Cloudflare]

When I turn on a page rule to “Always use HTTPS” and then I make a POST request to my API through Cloudflare, I get the error “The requested resource does not support http method ‘GET’.” Which is true–my API doesn’t respond to GET requests on the route in question. But I very clearly made a POST request when I got this response (not GET), so I’m wondering if the “Always use HTTPS” turns POST requests into GET requests? Am I not supposed to use this Page Rule on APIs like this…?

I think the APIs are supposed to call the right path from the get go. See this discussion on the potential non-idempotent nature of a post request. We’re definitely doing a 301 or 302 redirect depending on how you’re doing the redirect. Not sure that we offer the 307 option today.

Is this causing issues for you or was this more of a WTH type question?

Yeah, that makes sense. I wouldn’t say it’s causing an “issue.” It
definitely forces a certain design direction, but maybe this is not only
best practice but also kind of the only way to do it–you can’t rely on
redirects to maintain the integrity of POST API calls. I can live with
that. Thanks for the reply.

1 Like

There was an interesting post from Scott Helme recently where he used Cloudflare Edge Side Code to issue 308 responses for this very reason:

1 Like

Ah that’s brilliant @michael, thank you for sharing. One of my teammates likely wrote that code, I’ll have to go take a look at the specifics of it. Hopefully when we release Cloudflare Workers customers will be able to self service that functionality where needed. :slight_smile:

Maybe 301 isn’t “good enough” in theory, but that’s the only status that works to inherit Facebook share counts and that what actually matters for publishers.

With 307 HTTP to HTTPS headers getting all FB counters reset to 0.