mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Klues <>
Subject Re: Should "read-only" HTTP endpoints allow other request methods than "GET"?
Date Tue, 10 May 2016 15:52:18 GMT
There was some discussion of this between mpark and I in relation to
the v1 operator API.  The idea was to have a base class for endpoints
that implement GET/POST/DELETE/PUT/etc... functions that return an
error by default. You can then override the specific subset of them
that that each endpoint supports.

On Tue, May 10, 2016 at 6:42 AM, Vinod Kone <> wrote:
> +1 to only allow GET for read only
> @vinodkone
>> On May 10, 2016, at 6:37 AM, Jan Schlicht <> wrote:
>> Hi guys,
>> while working on HTTP endpoint authorization for Mesos, I found some
>> interesting behavior: It's the responsibility of the HTTP endpoint handlers
>> to validate the HTTP request method they've been called with. Many
>> "read-only" endpoints (e.g. "/flags", "/state") don't do this at the
>> moment. This means that it's possible to send, for example, an HTTP "POST"
>> to the "/state" endpoint and get the same results as if it would have been
>> an HTTP "GET".
>> While this is currently not a problem, it will complicate things when we
>> want to authorize endpoint access. The authorization should take the HTTP
>> request method into account to distinguish between "user wants read access
>> to the endpoint" and "user wants write access to the endpoint". This makes
>> it ambitious on how to handle these "read-only" endpoints that also accept
>> a "POST" request.
>> The solution to that problem would be to add HTTP request method validation
>> to every endpoint, i.e. the read-only endpoints would reject any request
>> method that isn't "GET". I've created MESOS-5346 for that.
>> Because that would change the existing behavior, that allows to e.g. "POST"
>> to a "read-only" endpoint, I'd like to know if anybody relies on that
>> behavior, or if there are any other objections on changing it.
>> Cheers,
>> Jan


View raw message