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.

An open question with this strategy is how --index-route would work. It should be possible to handle requests like POST /, the behavior of which could be configured via separate options like --get-index-route, --post-index-route, --put-index-route, etc. Alternatively --index-route could perhaps go away entirely and users would instead add files to the content directory root named get.*, post.*, put.*, etc (at the moment I'm liking this latter option).

Also, should --error-handler-route be split into separate options for each HTTP method? If not, the method could be added to RenderData (a good idea in any case) and the single error handler file could branch on that. Perhaps --error-handler-route could also go away and instead there could be a specially-named file at the content directory route (e.g. error-handler.*) which would be used if present (I'm liking this latter option too, especially if I do the same for --index-route).

[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).

[mkantor]

Giving users control over response headers and status codes seems important with methods like POST.