HTTP Response for PUT vs POST

[John Meinel]

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 <john at arbash-meinel.com> 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
> =:->
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140529/2a96f312/attachment.html>