It also returns a "text/plain" response rather than an application/json one. So we aren't actually encoding the error into a JSON response. I can workaround the Post vs Put stuff by just registering all handlers and leaving the code in place that just checks for only POST, but it seemed a bit of a shame to not leverage a helper that wants to help us out. John =:->
On Thu, May 29, 2014 at 3:14 PM, John Meinel <[email protected]> wrote: > We currently have a test that we get 401 Unauthorized when you try to do a > PUT instead of a POST for stuff like trying to push up Tools, etc. > > However, HTTP Spec seems to have a 405 Method Not Allowed, which is meant > to handle this case of PUT isn't allowed, but POST would be. > > I'm looking into changing our Mux layer, to one that separately handles > PUT from POST and will give us 405 codes "for free". > > I just wanted to check that it is probably a good idea to conform more to > the spec, and be returning 405, I'm guessing 401 here was just because that > was what we had on hand. > > The current way actually checks for POST before checking the > Authorization, so an invalid Auth'd PUT would return a 405 rather than 401, > but that doesn't seem like bad information leakage. > > Is that ok? > > John > =:-> >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
