If a service wants to provide forms with "additional methods" today, it must tunnel them through POST to make the service usable from a current user agent. We need to keep that mechanism around, so that services can be compatible with current user agents while at the same time allowing new clients to use the new feature.

As a service implementor, I need to recognize if I must remain backward compatible and respond with a POST form that tunnels a PUT or DELETE, or if the client would rather receive a form with PUT or DELETE action.

Proposal: let the http forms extension spec define an rfc7240 preference token "http-forms-extension" through which a client may express that it prefers forms following the extension draft, and register it according to rfc7240.

Proposed exchange with Prefer header:

Request:

GET /api/events/1234 HTTP/1.1
Host: example.org
Prefer: http-forms-extension

Response:

200 OK
Preference-Applied: http-forms-extension

...
<h1>An Obsolete Event</h1>
<form action="/api/events/1234" method="DELETE">
    <button type="submit">Delete</button>
</form>
...

Example exchange without Prefer header, using a backward compatible, non-standard, tunneled DELETE that works with current user agents:

Request:

GET /api/event HTTP/1.1
Host: example.org

Response:

200 OK

...
<h1>An Obsolete Event</h1>
<form action="/api/events/1234" method="POST">
    <input type="hidden" name="_method" value="DELETE"
    <button type="submit">Delete</button>
</form>
...