3830Re: [rest-discuss] 403 vs. 409
- Aug 1, 2003That's what I thought, except when I was working on Jot (my RESTful blog
system) someone (forgot who) said that 400 indicated a problem with HTTP
layer itself (e.g. "host" header missing in HTTP/1.1) and should not be used
for application-level errors. Currently, I am using 403, saying that an
invalid request entity (say, a non-well-formded XML document) would be
"forbidden". But the problem here is that the resource is what defines
whether the request entity is valid or not (even the well-formedness of an
XML document), so in *some* sense, a bad request entity "conflicts" with the
So, supposing that 409 was the correct response to use, then what is 403
for? About the only example I could come up with was one mirroring a
filesystem operation. Suppose you have a resource that is marked
"read-only". An attempt to PUT to that resource may be valid if it were not
read-only, but otherwise would return a 403. This is not a conflict,
necessarily (though I could see it rephrased that way), and therefore not
appropriate for a 409 response.
From: "Mark Baker" <distobj@...>
> On Thu, Jul 31, 2003 at 09:11:23AM -0400, Seairth Jacobs wrote:
> > Suppose an application detects a problem with the request entity.
> > 403 (forbidden) or a 409 (conflict) be returned?
> I'd use 400. Neither 403 nor 409 seem relevant.
- << Previous post in topic Next post in topic >>