3837Re: [rest-discuss] 403 vs. 409
- Aug 3, 2003Mark,
> > What would you be telling intermediaries if you used 200 to replyWell, in my *inexperience* that looks like a loss of visibility. I
> > to a POST of some malformed content:
> > a. that something was successfully appended or annotated?
> > b. that some data processing was successfully performed?
> b, I'd say, keeping in mind that "successful data processing" can
> include the determination of some "invalid" information within that
> data, such as non-well-formed XML, or an invalid credit card number.
> Where you draw this line is up to the needs of your application,
> which is why I say "sometimes 400, sometimes 200" (but mostly 200,
> in my experience).
syntax error to be a condition that aborts meaningful processing, and this
is application level protocol, so the status code should tell us about how
effectively state was transferred, not how effectively bits were
>"Back" seems more like a browser idiom. I would say that the absence
> > Why wouldn't 400 in this case be the ideal way to drive the
> > application in asking for the data again after correcting syntax?
> > How does 400 prevent the application from making progress?
> Because it's an error. An error response describes the specifics of the
> error, leaving the client no way to proceed through the application,
> except to do a logical "Back"; as far as the state of the application is
> concerned (which the client maintains), that interaction never happened.
of a 2xx is the absence of a forward transition, which leaves application
right where it was. In this case, the "way to proceed" is to correct syntax
and try again. What am I missing?
Another thought: the details of a malformed request and an aborted
state transition are analogous to (or perhaps just examples of)
conversational state. Not part of the "application state" model.
>Ah, thanks. So it would seem the part of 2616 that says 400 is about
> > Also, in general, where did I get the impression that an application
> > unsure about specific status codes can/should punt and use the x00
> > in the appropriate category? Doesn't seem to say that in 2616 for
> > the 400 family.
> Sec 6.1.1;
> "HTTP status codes are extensible. HTTP applications are not required
> to understand the meaning of all registered status codes, though such
> understanding is obviously desirable. However, applications MUST
> understand the class of any status code, as indicated by the first
> digit, and treat any unrecognized response as being equivalent to the
> x00 status code of that class, with the exception that an
> unrecognized response MUST NOT be cached."
syntax error specifically kind of violates that class/subclass thing, since
other 4xx responses are not about syntax. Season to taste?
- << Previous post in topic Next post in topic >>