The server only handles GET and OPTIONS requests

[mkantor]

Operator should support other HTTP methods. This goes hand-in-hand with #12.

[mkantor]

My first thought is to put control entirely in users' hands by structuring the content directory root to contain subdirectories for each method you want to handle:

content/
  get/
    whatever.html
  post/
    whatever.html.rb

There wouldn't be any difference between the verbs as far as Operator is concerned, it's just a routing mechanism. It'd be up to you to follow how the HTTP spec says each method should be used (or not). This would probably only make sense for GET/POST/PUT/PATCH/DELETE, not OPTIONS/TRACE/CONNECT/HEAD (those would be handled by Operator itself).

This seems easy to implement, but that doesn't mean it'll be the right approach. This requires more design work.

[mkantor]

A totally different approach would be to route all verbs to the same content files, and add the HTTP method to RenderData so executables can handle it as needed.

This could produce strange behavior with static files or executables/templates that don't check the verb. For example, DELETE /static-content would produce the same response as GET /static-content (and nothing would be deleted).

UPDATE: I've since veered sharply away from this. It was never a very good idea.

[mkantor]

#12 has been closed, but without including the request body or HTTP method in request data (neither are useful as long as Operator only handles GET).

Both are in scope for this issue, though. For implementation notes, see #12 (comment).

[mkantor]

#96 added basic support for OPTIONS. When other request methods are added the implementation of OPTIONS will need to become smarter (particularly if allowed methods can vary per-route). ContentEngine will probably know about the allowed methods for each route and can provide an accessor callable from http.rs to populate the Allow header as needed.

It'll probably also be a good idea to implement new CLI subcommands to mirror each HTTP method (operator options ..., operator post ..., etc).

[mkantor]

I'll probably open an issue specifically about request body handling after exploring more of the design space for this stuff, but in the meantime don't lose track of #12 (comment).