Kirby Panel not editable with Bunny CDN

Hey,

I have a problem with the Kirby Panel and Bunny CDN.
Every time I try to edit content on a page, for example switching a toggle, a request is sent to lock the page.

This request is a POST request with the x-http-method-override header set to PATCH. The response I get is a 404 No route found for path: "pages/test/lock" and request method: "POST.
The Bunny.net support responded that they strip the header internally before passing it back to the origin.

Is there a way to send the request as PATCH?

The source of your issue is here: kirby/panel/src/api/request.js at main · getkirby/kirby · GitHub

Where Kirby converts those request to POST requests and adds the x-http-method-override header. The problem is that this was necessary as many servers will block PATCH requests etc.

Not sure yet if/how we can handle servers that allow those but strip the header instead. Maybe @lukasbestle has an idea.

Yes, I have seen the issue on GitHub. Would be nice to have maybe a config setting for that.

At the moment we hardcode the methodOverwrite option to true. What we could do is to build a test route that is called once when the Panel loads, e.g. PATCH /api/system/method-test. The backend would return the request method it received. If the Panel gets a successful response with the correct method, we can set methodOverwrite to false, otherwise to true.

(Probably the option should rather be called methodOverride)

I think I’d rather go for the config option then. Having that call on every Panel (re-)load doesn’t feel great to me (also considering the niche need for it).

In my opinion, the config option would also be the best solution. But it might also be nice to have a area in the System Panel view to check these things manually or automatically when you visit the system view.

That’s true. I figure we could probably add a check to the tests that the system view runs - and if it fails show a warning with a link to the docs for the new config option.

Sounds great. We could even switch the default to proper HTTP methods and only offer the method override header as an option for those who need it (considering that the HTTP methods are standards-compliant and most server setups should be supporting them).