----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/62594/#review187497 -----------------------------------------------------------
src/scheduler/scheduler.cpp Lines 312-318 (patched) <https://reviews.apache.org/r/62594/#comment264518> So, this means the basic HTTP authenticatee is loaded and called into when the user specifies no authenticatee and no credential, right? The unfortunate thing about this is that we do an unnecessary copy of all HTTP requests in the authenticatee when the user has not opted in to authentication at all. I can imagine a few different ways to help alleviate this: 1) Store the authenticatee as an `Option`; the scheduler can call into it if it's SOME, otherwise synchronously invoke `_send()` 2) Have a `NoOpAuthenticatee` which simply returns the same request 3) Alter the logic in the basic authenticatee to avoid one of the extra copies if credential is NONE What do you think; is this worth addressing? Or not a big deal? - Greg Mann On Oct. 2, 2017, 10:29 a.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/62594/ > ----------------------------------------------------------- > > (Updated Oct. 2, 2017, 10:29 a.m.) > > > Review request for mesos, Anand Mazumdar, Armand Grillet, Benjamin Bannier, > Greg Mann, Kapil Arya, and Vinod Kone. > > > Bugs: MESOS-8021 > https://issues.apache.org/jira/browse/MESOS-8021 > > > Repository: mesos > > > Description > ------- > > Allows the scheduler library to load an HTTP authenticatee module > providing custom mechanisms for authentication. > > > Diffs > ----- > > src/scheduler/flags.hpp 1e8efc06b40b17d6fa9d9516a83893485804fc72 > src/scheduler/scheduler.cpp 78f53707364ab988bcc53ec2c95490df04cd9a6c > > > Diff: https://reviews.apache.org/r/62594/diff/4/ > > > Testing > ------- > > Integration test in external project. Further tests upcoming. > > > Thanks, > > Till Toenshoff > >
