method with Dream.form_tag

[zoggy]

It could be useful to be able to select between POST and GET for the method attribute of the <form> tag returned by Dream.form_tag. And GET could not use CSRF token. This would be useful when you want to allow sharing URLs for queries.

[aantron]

How about two separate arguments, ?method_ : method_, and csrf_token : bool?

[zoggy]

It seems even better ! Thanks !

[aantron]

Added by the linked commit :) Thanks for the request/feedback.

[tmattio]

@aantron the HTML form's method attribute only supports GET and POST (c.f. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Form#attributes_for_form_submission)

So the type of method_ should probably be ?method_:[ `GET | `POST ].

Alternatively, it is common to add an input containing the method to use and change the HTTP method of the request with the value of this input before it is routed to the handler/controller.

Opium has a middleware for this: https://github.com/rgrinberg/opium/blob/master/opium/src/middlewares/middleware_method_override.ml

As well as Plug: https://hexdocs.pm/plug/Plug.MethodOverride.html

[aantron]

@tmattio the link, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Form#attributes_for_form_submission, also says that method can be dialog, which I didn't even know about (and isn't an HTTP method, it seems, but has meaning inside HTML). dialog can at least be encoded with `Method "dialog". At least, to support all of this, method_ should have type more than [ `GET | `POST ].

So far, my idea was to let the Dream user use any method, and leave HTML compliance up to them on this matter. I am aware that forms officially support only GET and POST over HTTP.

Method override seems like a separate issue, and the way I typed method_ is not based on an attempt to "get" method override. It's just (maybe too) loose typing.

What do you suggest in light of dialog?

[tmattio]

Makes sense! I didn't know if it was an intentional deviation from the spec or an oversight, so I took the liberty to ping you 🙂

I never encountered dialog in the wild, so I have been ignoring it so far. If you prefer to deal with method overrides in another issue, I guess keeping `Method "dialog" as a workaround works just fine. An alternative could be to define a form method type [`GET | `POST | `PUT | `DELETE | `PATCH | `DIALOG], but I don't see any huge benefit in doing so.

If you're willing to handle method overrides in Dream directly, I could propose a PR with a new built-in middleware and an input field in the form_tag function.

[aantron]

What's the natural use case for method override these days? I assume it's mainly for bypassing firewalls, but I'm also under the impression that firewalls which block methods other than GET and POST are gradually being replaced (or reconfigured), so method override is becoming less and less needed over time. I wasn't able to find much information on real usage, however, so I'd be glad to learn :)

I opened #76 Method override middleware to continue the discussion of method override there.

[tmattio]

What's the natural use case for method override these days?

I've been using it to decouple what is an HTML implementation detail from the design of server APIs.

A common pattern for CRUD APIs is to use different HTTP methods for the same endpoint:

• GET /resource
• POST /resource
• PUT /resource
• DELETE /resource

This is not compatible with HTML forms, but I don't want the design of my APIs to be the result of a limitation in the HTML spec, so I use method overrides to work around this instead.

Apart from this, I am not familiar with specific use cases that are technically blocked without the support of method overrides.

[aantron]

FYI the upcoming release includes #201, in which Dream.csrf_tag supersedes Dream.form_tag. Dream_csrf_tag generates the CSRF <input> field separately, leaving the <form> tag open for the user to write as they please.