rack-mini-profile documentation needs to be clearer about what it does to requests & cookies

[mipearson]

Reading through profiler.rb I see lots of magic in there to manipulate caching & set cookies , mainly for good reasons (as detailed in the comments).

I think that this stuff needs to be added to the default documentation so that developers are aware that it will change the caching semantics of the request significantly if enabled in production. I can imagine a frustrated developer wondering why caching & ETags are behaving weirdly in production for them but not for those without miniprofiler enabled.

Furthermore, if my reading of the source is accurate, if a user is authorized to view MiniProfiler, and then that authorization is removed, they will still be able to view MiniProfiler as they'll have a client-side MiniProfiler session cookie. This caused me some confusion as I was debugging another issue and trying to work out why I was seeing performance degredation even though I'd removed MiniProfiler access for all users.

[SamSaffron]

Please, improving the documentation would be an awesome thing.

"they will still be able to view MiniProfiler as they'll have a client-side MiniProfiler session cookie"

no it does a second check, that just allows stuff to profile, then at the end it does another check, nukes the cookie and dumps the results.

[mipearson]

Unfortunately I'm not offering to do so: as evidenced, I'm worried that I'd
get it wrong.

On Mon, May 20, 2013 at 9:48 AM, Sam [email protected] wrote:

Please, improving the documentation would be an awesome thing.

"they will still be able to view MiniProfiler as they'll have a
client-side MiniProfiler session cookie"

no it does a second check, that just allows stuff to profile, then at the
end it does another check, nukes the cookie and dumps the results.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/157#issuecomment-18127144
.

Michael Pearson