Loading ...
Sorry, an error occurred while loading the content.

RE: [rest-discuss] 403 vs. 409

Expand Messages
  • David John Powell
    ... a ... talks ... it ... Well all 4xx codes indicate a problem with the request. Have you got a specific example? Do you mean something like missing required
    Message 1 of 26 , Aug 1, 2003
    • 0 Attachment
      >Suppose an application detects a problem with the request entity. Should
      a
      >403 (forbidden) or a 409 (conflict) be returned? Only 409 talks about
      >informing the client of how the problem might be fixed. However, 409
      talks
      >about conflicts with the resource. I would not consider an error in the
      >request entity to be a "conflict", as it was never even compared to the
      >existing resource (if one even exists). On the other hand, 403 doesn't
      >contain any language about correcting the problem and trying again (but
      it
      >also doesn't say *not* to do so), though it does say that the response
      >should indicate the problem.
      >
      >So, is 403 the prefered response or is it 409?
      >


      Well all 4xx codes indicate a problem with the request.
      Have you got a specific example? Do you mean something like missing
      required information from a POST request?

      I tend to use 400 for that sort of error, but I just checked, and 400
      is explicitly for syntactic errors, rather than semantic ones. So I
      guess that that isn't really right either. Is 400 intended only for
      syntactic errors at the HTTP level such as illegal URIs, or would it
      be allowed for syntactic errors at a higher level, such as if you
      tried to PUT or POST a corrupt document, or refered to a badly formatted
      identifier?

      403 doesn't sound right to me, because I've always seen it as a kind
      of "get lost" response for requests that have broke some sort of
      out-of-band policy, such as for IP restricted sites, but I notice that
      in the HTTP1.0 RFC, the description of 403 suggests that it can
      be used when other status codes are inappropriate, but that is for
      1.0.

      WebDAV defines a "422 Unprocessable entity" status for semantic
      problems with the XML request, and uses 400 if the XML request is not
      properly formed. I don't see why WebDAV would be a special case here,
      so that sounds wrong too.

      I wouldn't worry about 403 not specifying that the body should contain
      instructions on how to remedy the problem though, because the text
      describing
      4xx codes in general says that the server SHOULD include a body describing
      the
      error for all of these codes.

      --
      Dave
    • Mark Baker
      ... I d use 400. Neither 403 nor 409 seem relevant. Mark.
      Message 2 of 26 , Aug 1, 2003
      • 0 Attachment
        On Thu, Jul 31, 2003 at 09:11:23AM -0400, Seairth Jacobs wrote:
        > Suppose an application detects a problem with the request entity. Should a
        > 403 (forbidden) or a 409 (conflict) be returned?

        I'd use 400. Neither 403 nor 409 seem relevant.

        Mark.
      • Seairth Jacobs
        That 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
        Message 3 of 26 , Aug 1, 2003
        • 0 Attachment
          That'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
          resource.

          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.

          ---
          Seairth Jacobs
          seairth@...

          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.
          Should a
          > > 403 (forbidden) or a 409 (conflict) be returned?
          >
          > I'd use 400. Neither 403 nor 409 seem relevant.
        • Mark Baker
          Ah, Seairth was asking *that* question. I didn t realize. We should add this to the FAQ, as we ve had this twice before I think. Sometimes it s 400,
          Message 4 of 26 , Aug 1, 2003
          • 0 Attachment
            Ah, Seairth was asking *that* question. I didn't realize. We should
            add this to the FAQ, as we've had this twice before I think.

            Sometimes it's 400, sometimes it's 200. It depends on the method too.
            For PUT, I'd use 400, because to return 200 would be telling
            intermediaries that what was sent, was stored. For POST, more than
            likely I'd use 200, because I may want to resolve the bad data problem
            by, for example, driving the application to ask for the data again,
            and perhaps I want to count the retries or some such. If I used 400,
            then the application makes no progress, so I can't do that. I think.
            Funny how such a seemingly simple question opens up the whole "state"
            can-o-worms.

            Mark.
          • Julian Reschke
            ... RFC2616 says: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
            Message 5 of 26 , Aug 2, 2003
            • 0 Attachment
              > From: David John Powell [mailto:djpowell@...]
              > Sent: Friday, August 01, 2003 10:30 AM
              > To: rest-discuss@yahoogroups.com
              > Subject: RE: [rest-discuss] 403 vs. 409
              >
              >
              > ...
              >
              > Well all 4xx codes indicate a problem with the request.
              > Have you got a specific example? Do you mean something like missing
              > required information from a POST request?
              >
              > I tend to use 400 for that sort of error, but I just checked, and 400
              > is explicitly for syntactic errors, rather than semantic ones. So I
              > guess that that isn't really right either. Is 400 intended only for
              > syntactic errors at the HTTP level such as illegal URIs, or would it
              > be allowed for syntactic errors at a higher level, such as if you
              > tried to PUT or POST a corrupt document, or refered to a badly formatted
              > identifier?

              RFC2616 says:

              "The request could not be understood by the server due to malformed syntax.
              The client SHOULD NOT repeat the request without modifications."

              So it seems that's perfectly OK to indicate syntax problems in the request
              body using 400.

              > 403 doesn't sound right to me, because I've always seen it as a kind
              > of "get lost" response for requests that have broke some sort of
              > out-of-band policy, such as for IP restricted sites, but I notice that
              > in the HTTP1.0 RFC, the description of 403 suggests that it can
              > be used when other status codes are inappropriate, but that is for
              > 1.0.

              "The server understood the request, but is refusing to fulfill it.
              Authorization will not help and the request SHOULD NOT be repeated. If the
              request method was not HEAD and the server wishes to make public why the
              request has not been fulfilled, it SHOULD describe the reason for the
              refusal in the entity. If the server does not wish to make this information
              available to the client, the status code 404 (Not Found) can be used
              instead."

              > WebDAV defines a "422 Unprocessable entity" status for semantic
              > problems with the XML request, and uses 400 if the XML request is not
              > properly formed. I don't see why WebDAV would be a special case here,
              > so that sounds wrong too.

              Could you please explain why you think this is wrong?

              > ...

              Julian

              --
              <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
            • Walden Mathews
              Mark, What would you be telling intermediaries if you used 200 to reply to a POST of some malformed content: a. that something was successfully appended or
              Message 6 of 26 , Aug 2, 2003
              • 0 Attachment
                Mark,

                What would you be telling intermediaries if you used 200 to reply
                to a POST of some malformed content:

                a. that something was successfully appended or annotated?
                b. that some data processing was successfully performed?

                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?

                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.

                Walden

                ----- Original Message -----
                From: "Mark Baker" <distobj@...>
                To: <rest-discuss@yahoogroups.com>
                Sent: Saturday, August 02, 2003 12:38 AM
                Subject: Re: [rest-discuss] 403 vs. 409


                > Ah, Seairth was asking *that* question. I didn't realize. We should
                > add this to the FAQ, as we've had this twice before I think.
                >
                > Sometimes it's 400, sometimes it's 200. It depends on the method too.
                > For PUT, I'd use 400, because to return 200 would be telling
                > intermediaries that what was sent, was stored. For POST, more than
                > likely I'd use 200, because I may want to resolve the bad data problem
                > by, for example, driving the application to ask for the data again,
                > and perhaps I want to count the retries or some such. If I used 400,
                > then the application makes no progress, so I can't do that. I think.
                > Funny how such a seemingly simple question opens up the whole "state"
                > can-o-worms.
                >
                > Mark.
                >
                >
                > To unsubscribe from this group, send an email to:
                > rest-discuss-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
                >
                >
              • Mark Baker
                Hey Walden, ... b, I d say, keeping in mind that successful data processing can include the determination of some invalid information within that data,
                Message 7 of 26 , Aug 2, 2003
                • 0 Attachment
                  Hey Walden,

                  On Sat, Aug 02, 2003 at 01:49:55PM -0400, Walden Mathews wrote:
                  > Mark,
                  >
                  > What would you be telling intermediaries if you used 200 to reply
                  > 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).

                  > 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.

                  > 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."

                  Mark.
                  --
                  Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                • Seairth Jacobs
                  So far, all I am seeing is that just about everyone has a different take on whether to use 400, 403, or 409 (and maybe even 200 for POSTs). I realize that
                  Message 8 of 26 , Aug 2, 2003
                  • 0 Attachment
                    So far, all I am seeing is that just about everyone has a different take on
                    whether to use 400, 403, or 409 (and maybe even 200 for POSTs). I realize
                    that there are cut-and-dried cases that no one would argue with, but for
                    these other cases where everyone seems to have a different opinion, I am
                    wondering if maybe the best approach is to just pick the response(s) that
                    seem appropriate and document the decision. In the end, I may choose to use
                    403 where some (though not all) others think 409 would be more appropriate.
                    However, as long as the documentation clearly indicates which responses to
                    expect for which occasions, can we all accept the difference of opinion and
                    move on? I have continued to implement my code using 403 and have not yet
                    seen any compelling reasons to change it. As long as people working with my
                    documented interface know that 403 is the expected response (among others),
                    does it really matter?

                    ---
                    Seairth Jacobs
                    seairth@...
                  • Walden Mathews
                    Mark, ... Well, in my *inexperience* that looks like a loss of visibility. I understand syntax error to be a condition that aborts meaningful processing, and
                    Message 9 of 26 , Aug 3, 2003
                    • 0 Attachment
                      Mark,

                      > > What would you be telling intermediaries if you used 200 to reply
                      > > 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).

                      Well, in my *inexperience* that looks like a loss of visibility. I
                      understand
                      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
                      transported.

                      >
                      > > 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.

                      "Back" seems more like a browser idiom. I would say that the absence
                      of a 2xx is the absence of a forward transition, which leaves application
                      state
                      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.

                      >
                      > > 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."

                      Ah, thanks. So it would seem the part of 2616 that says 400 is about
                      syntax error specifically kind of violates that class/subclass thing, since
                      other 4xx responses are not about syntax. Season to taste?

                      -Walden
                    • David Powell
                      ... I just don t think that it is a WebDAV specific problem, so I would expect WebDAV to use whatever status would be appropriate for any other HTTP
                      Message 10 of 26 , Aug 4, 2003
                      • 0 Attachment
                        Saturday, August 2, 2003, 9:36:07 AM, you wrote:

                        >> WebDAV defines a "422 Unprocessable entity" status for semantic
                        >> problems with the XML request, and uses 400 if the XML request is not
                        >> properly formed. I don't see why WebDAV would be a special case here,
                        >> so that sounds wrong too.

                        > Could you please explain why you think this is wrong?

                        I just don't think that it is a WebDAV specific problem, so I would
                        expect WebDAV to use whatever status would be appropriate for any
                        other HTTP application.

                        I tend to favour 400, but it looks as if 422 was invented for WebDAV
                        because it was decided that 400 couldn't be used to report errors that
                        weren't strictly syntactic?


                        --
                        Dave
                      • Julian Reschke
                        ... So you think this is wrong because WebDAV added a new status code? I can t agree -- the whole point of WebDAV is to *extend* HTTP/1.1 (with new methods,
                        Message 11 of 26 , Aug 4, 2003
                        • 0 Attachment
                          > From: David Powell [mailto:djpowell@...]
                          > Sent: Monday, August 04, 2003 9:08 AM
                          > To: rest-discuss@yahoogroups.com
                          > Subject: Re: [rest-discuss] 403 vs. 409
                          >
                          >
                          > Saturday, August 2, 2003, 9:36:07 AM, you wrote:
                          >
                          > >> WebDAV defines a "422 Unprocessable entity" status for semantic
                          > >> problems with the XML request, and uses 400 if the XML request is not
                          > >> properly formed. I don't see why WebDAV would be a special case here,
                          > >> so that sounds wrong too.
                          >
                          > > Could you please explain why you think this is wrong?
                          >
                          > I just don't think that it is a WebDAV specific problem, so I would
                          > expect WebDAV to use whatever status would be appropriate for any
                          > other HTTP application.

                          So you think this is wrong because WebDAV added a new status code? I can't
                          agree -- the whole point of WebDAV is to *extend* HTTP/1.1 (with new
                          methods, request headers...), and therefore adding a new specific 4xx status
                          code because none of the existing ones fitted well seems to be absolutely
                          right thing to do.

                          > I tend to favour 400, but it looks as if 422 was invented for WebDAV
                          > because it was decided that 400 couldn't be used to report errors that
                          > weren't strictly syntactic?

                          Julian

                          --
                          <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                        • Alex Jacobson
                          Why isn t the correct response 415 (Unsupported Media Type)? Your application requires that the POST conform to a particular schema and that schema has been
                          Message 12 of 26 , Aug 4, 2003
                          • 0 Attachment
                            Why isn't the correct response 415 (Unsupported Media Type)?

                            Your application requires that the POST conform to a particular schema and
                            that schema has been violated. 2616 does not say that the value of the
                            content-type header is bad, but that the actual media-type is bad. XML DTD
                            and schema have already moved a lot of media-type information outside of
                            the content-type header. Isn't 415 the status code to use if the client is
                            violating schema requirements?

                            -Alex-

                            ___________________________________________________________________
                            S. Alexander Jacobson i2x Media
                            1-212-787-1914 voice 1-603-288-1280 fax


                            --On Friday, August 01, 2003 4:07 PM -0400 Seairth Jacobs
                            <seairth@...> wrote:

                            > That'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 resource.
                            >
                            > 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.
                            >
                            > ---
                            > Seairth Jacobs
                            > seairth@...
                            >
                            > 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.
                            > Should a
                            >> > 403 (forbidden) or a 409 (conflict) be returned?
                            >>
                            >> I'd use 400. Neither 403 nor 409 seem relevant.
                            >
                            >
                            >
                            >
                            > To unsubscribe from this group, send an email to:
                            > rest-discuss-unsubscribe@yahoogroups.com
                            >
                            >
                            >
                            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                            >
                            >
                          • Alex Jacobson
                            Seairth, I just took a look at your blog and your comments on Jot/ReSTful blog architecture and at RNA and
                            Message 13 of 26 , Aug 4, 2003
                            • 0 Attachment
                              Seairth, I just took a look at your blog and your comments on Jot/ReSTful
                              blog architecture and at RNA <http://www.seairth.com/blog/industry/49> and
                              <http://www.seairth.com/blog/jot/docs/6> <http://www.seairth.com/web/rna/>

                              These specs strike me as excessively complex. By forcing applications
                              interface specifications to include both a set of verbs and the
                              content-types/schemas allowed w/r/t those verbs we lose all the visibility
                              and genericity that ReST is intended to promise.

                              If we had a standard mapping between HTTP methods and underlying
                              content-types, everything would get MUCH simpler. The most useful mapping
                              would be from HTTP to XML and would probably look something like this:

                              GET /myRSSblog returns an XML document.
                              POST /myRSSblog#channelId adds a new child to the XML node with that id.
                              GET /myRSSblog#itemId returns an XML node with that id
                              PUT /myRSSblog#itemId replaces the XML node with that id
                              DELETE /myRSSblog#itemId deletes the XML node with that id
                              (Style using <?xml-stylesheet type="text/xsl" href="yourstyle.xsl"?> for
                              your viewing pleasure.)

                              Now you don't need any special purpose plumbing for indexing, mapping to
                              directory structure, or all sorts of other annoying administrivia. If you
                              are maintaing a blog and you want to switch from RSS to nEcho just use an
                              xslt transform and update your stylesheet. No special purpose plumbing
                              required....

                              Similarly, you can simplify the RNA spec to an addressbook/subscribers
                              schema and an INBOX schema. Sending messages obviously is just a POST to
                              an inbox, etc.

                              For total coverage, a wiki is also just an XML document with client-side
                              javascript placed in the stylesheet that does the wikitext rendering. You
                              can even standardize the rendering by using a script-src rather than
                              bundling your own (it is also, therefore, more likely to be cached). The
                              existing wiki systems encourage proliferation of wikitext formats because
                              the rendering is done on the servers.

                              Thoughts? Any reason why things need to be more complex than this?

                              -Alex-

                              PS The point of my advocating Model State Transfer over Representational
                              State Transfer is precisely that I think ReST forces servers to implement
                              all sorts of special purpose plumbing to hide the data model rather than
                              just assuming that other agents (perhaps residing on the server) will do
                              data model conversions if needed. I'd like to get to get rid of
                              content-negotiation and get to the point where the content-type/xml-schema
                              of a resource is all you need to know in order to interact with it.

                              ___________________________________________________________________
                              S. Alexander Jacobson i2x Media
                              1-212-787-1914 voice 1-603-288-1280 fax




                              --On Friday, August 01, 2003 4:07 PM -0400 Seairth Jacobs
                              <seairth@...> wrote:

                              > That'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 resource.
                              >
                              > 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.
                              >
                              > ---
                              > Seairth Jacobs
                              > seairth@...
                              >
                              > 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.
                              > Should a
                              >> > 403 (forbidden) or a 409 (conflict) be returned?
                              >>
                              >> I'd use 400. Neither 403 nor 409 seem relevant.
                              >
                              >
                              >
                              >
                              > To unsubscribe from this group, send an email to:
                              > rest-discuss-unsubscribe@yahoogroups.com
                              >
                              >
                              >
                              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                              >
                              >
                            • David Powell
                              ... JR So you think this is wrong because WebDAV added a new status code? I can t JR agree -- the whole point of WebDAV is to *extend* HTTP/1.1 (with new JR
                              Message 14 of 26 , Aug 4, 2003
                              • 0 Attachment
                                >> Saturday, August 2, 2003, 9:36:07 AM, you wrote:
                                >>
                                >> >> WebDAV defines a "422 Unprocessable entity" status for semantic
                                >> >> problems with the XML request, and uses 400 if the XML request is not
                                >> >> properly formed. I don't see why WebDAV would be a special case here,
                                >> >> so that sounds wrong too.
                                >>
                                >> > Could you please explain why you think this is wrong?
                                >>
                                >> I just don't think that it is a WebDAV specific problem, so I would
                                >> expect WebDAV to use whatever status would be appropriate for any
                                >> other HTTP application.

                                JR> So you think this is wrong because WebDAV added a new status code? I can't
                                JR> agree -- the whole point of WebDAV is to *extend* HTTP/1.1 (with new
                                JR> methods, request headers...), and therefore adding a new specific 4xx status
                                JR> code because none of the existing ones fitted well seems to be absolutely
                                JR> right thing to do.

                                I wasn't trying to pick on WebDAV. I have no problem with WebDAV
                                inventing new codes. I was just trying to figure out what was the best
                                status to return for a semantic error in HTTP, and WebDAV was a good
                                case study because it invents a new code for this purpose. If WebDAV
                                had to invent a new code, then does that mean that this is a situation
                                that HTTP/1.1 doesn't cater for?

                                What I am really trying to figure out is whether 400 is allowed for
                                requests that are syntactically correct at the HTTP level, but have a
                                semantic error. I always thought that it was OK, because it looks
                                like the most appropriate code. I'm assuming that WebDAV invented
                                422, because it considered it not to be OK - but I don't really know
                                the history.



                                --
                                Best regards,
                                David mailto:djpowell@...
                              • Julian Reschke
                                ... It seems that this is just a shortcoming in HTTP. 4xx is for client errors. We are definitvely talking about a client error. In the absence of a more
                                Message 15 of 26 , Aug 4, 2003
                                • 0 Attachment
                                  > From: David Powell [mailto:djpowell@...]
                                  > Sent: Monday, August 04, 2003 9:43 PM
                                  > To: rest-discuss@yahoogroups.com
                                  > Subject: Re: [rest-discuss] 403 vs. 409
                                  >
                                  >
                                  > ...
                                  >
                                  > I wasn't trying to pick on WebDAV. I have no problem with WebDAV
                                  > inventing new codes. I was just trying to figure out what was the best
                                  > status to return for a semantic error in HTTP, and WebDAV was a good
                                  > case study because it invents a new code for this purpose. If WebDAV
                                  > had to invent a new code, then does that mean that this is a situation
                                  > that HTTP/1.1 doesn't cater for?
                                  >
                                  > What I am really trying to figure out is whether 400 is allowed for
                                  > requests that are syntactically correct at the HTTP level, but have a
                                  > semantic error. I always thought that it was OK, because it looks
                                  > like the most appropriate code. I'm assuming that WebDAV invented
                                  > 422, because it considered it not to be OK - but I don't really know
                                  > the history.

                                  It seems that this is just a shortcoming in HTTP. 4xx is for client errors.
                                  We are definitvely talking about a client error. In the absence of a more
                                  specific code (401...), one would use 400. But 400 is defined as:

                                  "The request could not be understood by the server due to malformed syntax.
                                  The client SHOULD NOT repeat the request without modifications." (RFC2616:
                                  status 400)

                                  WebDAV defines 422 for:

                                  "The 422 (Unprocessable Entity) status code means the server understands the
                                  content type of the request entity (hence a 415(Unsupported Media Type)
                                  status code is inappropriate), and the syntax of the request entity is
                                  correct (thus a 400 (Bad Request) status code is inappropriate) but was
                                  unable to process the contained instructions. For example, this error
                                  condition may occur if an XML request body contains well-formed (i.e.,
                                  syntactically correct), but semantically erroneous XML instructions."
                                  (RFC2518)

                                  So the point of view seems to be that the request entitity indeed had
                                  wellformed syntax, but wasn't semantically valid. Now we all know that the
                                  boundaries between syntax and semantics aren't THAT well-defined. So even
                                  though the request body may be well-formed XML, an HTTP server could still
                                  claim a syntax error.

                                  It seems that the WebDAV WG didn't want to choose that direction and just
                                  defined a new, more specific status code. This is perfectly ok, any client
                                  that doesn't know 422 will have to treat it as 400, so no harm is done. As
                                  WebDAV is the product of an IETF working group (and is currently progressing
                                  to the next standards level), 422 is definitively here to stay, so I'd
                                  recommend just to adopt it.

                                  (it would be interesting to reseacg up how the WG came up with this design)

                                  Julian





                                  --
                                  <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                                • Seairth Jacobs
                                  Okay... now we are up to: 400 or 403 or 409 or 415 (or sometimes 200) I am unsure about using 415, though. If someone POSTs/PUTs an text/xml request entity
                                  Message 16 of 26 , Aug 4, 2003
                                  • 0 Attachment
                                    Okay... now we are up to:

                                    400
                                    or 403
                                    or 409
                                    or 415
                                    (or sometimes 200)


                                    I am unsure about using 415, though. If someone POSTs/PUTs an "text/xml"
                                    request entity (that happens to not be well-formed) and gets back a 415,
                                    how likely are they to know that it's the entity itself that's not valid,
                                    not necessarily the content-type they said it was? I know you could convey
                                    this information in the response entity, but let's face it, the only
                                    successful use of this is with HTML, which isn't at all program-friendly.
                                    As a result, you have one of the following choices:

                                    1) Use the code that's closest and hope the client understands it.
                                    2) Use 400 generally and come up with an xml-based (since the request was
                                    supposedly xml) response entity that conveys all possible information. Then
                                    make sure all clients know how to use this xml-based specification.
                                    3) Create a new 4xx response code that means *exactly* what you want it to
                                    mean. Then make sure all clients now how to handle that response code (or
                                    fall back to 400 equivalence and rely on option #1).

                                    ---
                                    Seairth Jacobs
                                    seairth@...

                                    ----- Original Message -----
                                    From: "Alex Jacobson" <alex@...>
                                    To: "Seairth Jacobs" <seairth@...>; "rest-discuss"
                                    <rest-discuss@yahoogroups.com>
                                    Sent: Monday, August 04, 2003 12:52 PM
                                    Subject: Re: [rest-discuss] 403 vs. 409


                                    > Why isn't the correct response 415 (Unsupported Media Type)?
                                    >
                                    > Your application requires that the POST conform to a particular schema and
                                    > that schema has been violated. 2616 does not say that the value of the
                                    > content-type header is bad, but that the actual media-type is bad. XML
                                    DTD
                                    > and schema have already moved a lot of media-type information outside of
                                    > the content-type header. Isn't 415 the status code to use if the client
                                    is
                                    > violating schema requirements?
                                    >
                                    > -Alex-
                                    >
                                    > ___________________________________________________________________
                                    > S. Alexander Jacobson i2x Media
                                    > 1-212-787-1914 voice 1-603-288-1280 fax
                                    >
                                    >
                                    > --On Friday, August 01, 2003 4:07 PM -0400 Seairth Jacobs
                                    > <seairth@...> wrote:
                                    >
                                    > > That'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 resource.
                                    > >
                                    > > 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.
                                    > >
                                    > > ---
                                    > > Seairth Jacobs
                                    > > seairth@...
                                    > >
                                    > > 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.
                                    > > Should a
                                    > >> > 403 (forbidden) or a 409 (conflict) be returned?
                                    > >>
                                    > >> I'd use 400. Neither 403 nor 409 seem relevant.
                                    > >
                                    > >
                                    > >
                                    > >
                                    > > To unsubscribe from this group, send an email to:
                                    > > rest-discuss-unsubscribe@yahoogroups.com
                                    > >
                                    > >
                                    > >
                                    > > Your use of Yahoo! Groups is subject to
                                    http://docs.yahoo.com/info/terms/
                                    > >
                                    > >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    > To unsubscribe from this group, send an email to:
                                    > rest-discuss-unsubscribe@yahoogroups.com
                                    >
                                    >
                                    >
                                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                    >
                                    >
                                    >
                                  • Mark Baker
                                    ... Agreed. If the state was transferred such that it was processed , then it s a success. One can, I believe, quite reasonably define processed to
                                    Message 17 of 26 , Aug 4, 2003
                                    • 0 Attachment
                                      On Sun, Aug 03, 2003 at 11:00:11AM -0400, Walden Mathews wrote:
                                      > > 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).
                                      >
                                      > Well, in my *inexperience* that looks like a loss of visibility. I
                                      > understand
                                      > 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
                                      > transported.

                                      Agreed. If the state was transferred such that it was "processed", then
                                      it's a success. One can, I believe, quite reasonably define "processed"
                                      to include determining whether an XML document was well-formed or not
                                      ... if that meets your needs.

                                      > > 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.
                                      >
                                      > "Back" seems more like a browser idiom. I would say that the absence
                                      > of a 2xx is the absence of a forward transition, which leaves application
                                      > state
                                      > right where it was. In this case, the "way to proceed" is to correct syntax
                                      > and try again. What am I missing?

                                      No, you got it, that's what I meant. "Back" from the "400 page", so to
                                      speak.

                                      > 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.

                                      Hmmm.. dunno.

                                      > > > 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."
                                      >
                                      > Ah, thanks. So it would seem the part of 2616 that says 400 is about
                                      > syntax error specifically kind of violates that class/subclass thing, since
                                      > other 4xx responses are not about syntax. Season to taste?

                                      Dunno, you'll have to ask the editors.

                                      Mark.
                                      --
                                      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                                    • Walden Mathews
                                      ... Sure, in that case your resource is just an XML parser, not an application that consumes well-formed and perhaps valid XML. ... the ... is ... happened.
                                      Message 18 of 26 , Aug 5, 2003
                                      • 0 Attachment
                                        > Agreed. If the state was transferred such that it was "processed", then
                                        > it's a success. One can, I believe, quite reasonably define "processed"
                                        > to include determining whether an XML document was well-formed or not
                                        > ... if that meets your needs.

                                        Sure, in that case your resource is just an XML parser, not an
                                        application that consumes well-formed and perhaps valid XML.

                                        >
                                        > > > 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.
                                        [snip]
                                        > No, you got it, that's what I meant. "Back" from the "400 page", so to
                                        > speak.

                                        Okay, then the application still has the same means for proceeding
                                        through the application that it did before the error. Should be no
                                        problem in terms of state machine.

                                        > > > "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."
                                        > >
                                        > > Ah, thanks. So it would seem the part of 2616 that says 400 is about
                                        > > syntax error specifically kind of violates that class/subclass thing,
                                        since
                                        > > other 4xx responses are not about syntax. Season to taste?
                                        >
                                        > Dunno, you'll have to ask the editors.

                                        Okay. Editors?

                                        --Walden
                                      • Mark Baker
                                        ... Even in the latter case, I d say it s just fine. If your application only consumes well formed XML on POST, then you *may* want to use 400, but 200 would
                                        Message 19 of 26 , Aug 5, 2003
                                        • 0 Attachment
                                          On Tue, Aug 05, 2003 at 07:50:30AM -0400, Walden Mathews wrote:
                                          > > Agreed. If the state was transferred such that it was "processed", then
                                          > > it's a success. One can, I believe, quite reasonably define "processed"
                                          > > to include determining whether an XML document was well-formed or not
                                          > > ... if that meets your needs.
                                          >
                                          > Sure, in that case your resource is just an XML parser, not an
                                          > application that consumes well-formed and perhaps valid XML.

                                          Even in the latter case, I'd say it's just fine. If your application
                                          only consumes well formed XML on POST, then you *may* want to use 400,
                                          but 200 would be valid as well.

                                          > > No, you got it, that's what I meant. "Back" from the "400 page", so to
                                          > > speak.
                                          >
                                          > Okay, then the application still has the same means for proceeding
                                          > through the application that it did before the error. Should be no
                                          > problem in terms of state machine.

                                          Except that the 400 response is supposed to describe the error, so it
                                          should be a dead-end from the POV of progressing the application.

                                          There's probably a more accurate way to describe that in terms of
                                          application state, but I can't come up with it right now.

                                          > > Dunno, you'll have to ask the editors.
                                          >
                                          > Okay. Editors?

                                          FWIW, 2xx is also like this, as 202 doesn't mean "processed". Henrik
                                          told me this was a legacy issue that wasn't felt to warrant changing
                                          the first-character rule.

                                          Mark.
                                          --
                                          Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                                        • Alex Jacobson
                                          If 415 means only that the server doesn t like the content-type header, its a pretty worthless status code. Following ward cunningham s FIT model for
                                          Message 20 of 26 , Aug 5, 2003
                                          • 0 Attachment
                                            If 415 means only that the server doesn't like the content-type header, its
                                            a pretty worthless status code.

                                            Following ward cunningham's FIT model for specifications, here is a table
                                            of conditions(hopefully your mailreader uses a fixed width font):

                                            content-type ctype
                                            content-type request-entity acceptable matchesbody entity-acceptable
                                            status
                                            text/plain JPEG No No No 415
                                            text/plain rss2 No No Yes ???
                                            text/xml rss.91 No Yes No 415
                                            text/xml rss2 No Yes Yes ???
                                            text/xml urlencoded Yes No No ???
                                            text/xml urlencoded Yes No Yes ???
                                            text/xml rss.91 Yes Yes No ???
                                            text/xml rss2 Yes Yes Yes 20x

                                            Answering your question formally means filling in this sort of table.

                                            To me, the only thing that matters is whether the entity-body is
                                            acceptable. Forcing content-type header checks is just an annoyance
                                            because usually only one sort of entity-body is acceptable and there are no
                                            "warning" status codes. I would fill in 415 on every line where
                                            entity-acceptable is no. What would you do?

                                            -Alex-

                                            ___________________________________________________________________
                                            S. Alexander Jacobson i2x Media
                                            1-212-787-1914 voice 1-603-288-1280 fax


                                            --On Monday, August 04, 2003 8:52 PM -0400 Seairth Jacobs
                                            <seairth@...> wrote:

                                            > Okay... now we are up to:
                                            >
                                            > 400
                                            > or 403
                                            > or 409
                                            > or 415
                                            > (or sometimes 200)
                                            >
                                            >
                                            > I am unsure about using 415, though. If someone POSTs/PUTs an "text/xml"
                                            > request entity (that happens to not be well-formed) and gets back a 415,
                                            > how likely are they to know that it's the entity itself that's not valid,
                                            > not necessarily the content-type they said it was? I know you could
                                            > convey this information in the response entity, but let's face it, the
                                            > only successful use of this is with HTML, which isn't at all
                                            > program-friendly. As a result, you have one of the following choices:
                                            >
                                            > 1) Use the code that's closest and hope the client understands it.
                                            > 2) Use 400 generally and come up with an xml-based (since the request was
                                            > supposedly xml) response entity that conveys all possible information.
                                            > Then make sure all clients know how to use this xml-based specification.
                                            > 3) Create a new 4xx response code that means *exactly* what you want it to
                                            > mean. Then make sure all clients now how to handle that response code (or
                                            > fall back to 400 equivalence and rely on option #1).
                                            >
                                            > ---
                                            > Seairth Jacobs
                                            > seairth@...
                                            >
                                            > ----- Original Message -----
                                            > From: "Alex Jacobson" <alex@...>
                                            > To: "Seairth Jacobs" <seairth@...>; "rest-discuss"
                                            > <rest-discuss@yahoogroups.com>
                                            > Sent: Monday, August 04, 2003 12:52 PM
                                            > Subject: Re: [rest-discuss] 403 vs. 409
                                            >
                                            >
                                            >> Why isn't the correct response 415 (Unsupported Media Type)?
                                            >>
                                            >> Your application requires that the POST conform to a particular schema
                                            >> and that schema has been violated. 2616 does not say that the value of
                                            >> the content-type header is bad, but that the actual media-type is bad.
                                            >> XML
                                            > DTD
                                            >> and schema have already moved a lot of media-type information outside of
                                            >> the content-type header. Isn't 415 the status code to use if the client
                                            > is
                                            >> violating schema requirements?
                                            >>
                                            >> -Alex-
                                            >>
                                            >> ___________________________________________________________________
                                            >> S. Alexander Jacobson i2x Media
                                            >> 1-212-787-1914 voice 1-603-288-1280 fax
                                            >>
                                            >>
                                            >> --On Friday, August 01, 2003 4:07 PM -0400 Seairth Jacobs
                                            >> <seairth@...> wrote:
                                            >>
                                            >> > That'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 resource.
                                            >> >
                                            >> > 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.
                                            >> >
                                            >> > ---
                                            >> > Seairth Jacobs
                                            >> > seairth@...
                                            >> >
                                            >> > 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.
                                            >> > Should a
                                            >> >> > 403 (forbidden) or a 409 (conflict) be returned?
                                            >> >>
                                            >> >> I'd use 400. Neither 403 nor 409 seem relevant.
                                            >> >
                                            >> >
                                            >> >
                                            >> >
                                            >> > To unsubscribe from this group, send an email to:
                                            >> > rest-discuss-unsubscribe@yahoogroups.com
                                            >> >
                                            >> >
                                            >> >
                                            >> > Your use of Yahoo! Groups is subject to
                                            > http://docs.yahoo.com/info/terms/
                                            >> >
                                            >> >
                                            >>
                                            >>
                                            >>
                                            >>
                                            >>
                                            >>
                                            >> To unsubscribe from this group, send an email to:
                                            >> rest-discuss-unsubscribe@yahoogroups.com
                                            >>
                                            >>
                                            >>
                                            >> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                            >>
                                            >>
                                            >>
                                            >
                                            >
                                            >
                                            > To unsubscribe from this group, send an email to:
                                            > rest-discuss-unsubscribe@yahoogroups.com
                                            >
                                            >
                                            >
                                            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                            >
                                            >
                                          • Joe Gregorio
                                            ... Have you looked at the AtomAPI[1][2], which is part of this effort[3]? [1] http://bitworking.org/news/AtomAPI_URIs [2]
                                            Message 21 of 26 , Aug 5, 2003
                                            • 0 Attachment
                                              Alex Jacobson wrote:
                                              > If we had a standard mapping between HTTP methods and underlying
                                              > content-types, everything would get MUCH simpler. The most useful mapping
                                              > would be from HTTP to XML and would probably look something like this:
                                              >
                                              > GET /myRSSblog returns an XML document.
                                              > POST /myRSSblog#channelId adds a new child to the XML node with that id.
                                              > GET /myRSSblog#itemId returns an XML node with that id
                                              > PUT /myRSSblog#itemId replaces the XML node with that id
                                              > DELETE /myRSSblog#itemId deletes the XML node with that id
                                              > (Style using <?xml-stylesheet type="text/xsl" href="yourstyle.xsl"?> for
                                              > your viewing pleasure.)

                                              Have you looked at the AtomAPI[1][2], which is part of this effort[3]?

                                              [1] http://bitworking.org/news/AtomAPI_URIs
                                              [2] http://bitworking.org/rfc/draft-gregorio-06.html
                                              [3] http://www.intertwingly.net/wiki/pie/FrontPage

                                              -joe

                                              --
                                              http://BitWorking.org
                                              http://WellFormedWeb.org
                                            • Seairth Jacobs
                                              From: Alex Jacobson ... its ... I disagree. For instance, if a resource is an JPG image and someone attempts to PUT a PNG image, without even
                                              Message 22 of 26 , Aug 5, 2003
                                              • 0 Attachment
                                                From: "Alex Jacobson" <alex@...>
                                                >
                                                > If 415 means only that the server doesn't like the content-type header,
                                                its
                                                > a pretty worthless status code.

                                                I disagree. For instance, if a resource is an JPG image and someone
                                                attempts to PUT a PNG image, without even looking at the entity-body, the
                                                server can reject the request. There is no need to waste time/resources
                                                processing the request entity to determine if it is even a JPG file since
                                                the content-type clearly states that it is not. Now, it may be that a
                                                mismatched content-type/request-entity should also be a 415, but you are the
                                                only one I have seen suggest it so far (not that it means your are wrong or
                                                anything, just a lack of consensus).

                                                > Following ward cunningham's FIT model for specifications, here is a table
                                                > of conditions(hopefully your mailreader uses a fixed width font):
                                                >
                                                > content-type ctype
                                                > content-type request-entity acceptable matchesbody entity-acceptable
                                                > status
                                                > text/plain JPEG No No No 415

                                                I agree.

                                                > text/plain rss2 No No Yes ???

                                                415 (acceptable = No)

                                                > text/xml rss.91 No Yes No 415

                                                Yes.

                                                > text/xml rss2 No Yes Yes ???

                                                415 (acceptable = No)

                                                > text/xml urlencoded Yes No No ???

                                                still ???

                                                > text/xml urlencoded Yes No Yes ???

                                                still ???

                                                > text/xml rss.91 Yes Yes No ???

                                                still ???

                                                > text/xml rss2 Yes Yes Yes 20x

                                                I agree.

                                                Or, in the format as above...

                                                text/plain JPEG No No No 415
                                                text/plain rss2 No No Yes 415
                                                text/xml rss.91 No Yes No 415
                                                text/xml rss2 No Yes Yes 415
                                                text/xml urlencoded Yes No No ???
                                                text/xml urlencoded Yes No Yes ???
                                                text/xml rss.91 Yes Yes No ???
                                                text/xml rss2 Yes Yes Yes 20x

                                                All of the remaining ??? fundamentally fail because the entity-body does not
                                                match the conent-type (whether the entity-body is valid in its own right or
                                                not).

                                                May be the question is if the failure is at the protocol level, application
                                                level, or the resource-state level. If the problem is at the HTTP level
                                                (where HTTP itself believes something to be wrong), I'd think 400 would be
                                                the correct response. If the problem is at the application level (which
                                                reads the entity-body and attempts to make sense of it), I'd think 403 is
                                                the correct response. If the problem is at the resource-state level (where
                                                accepting the entity body would leave the resource in an invalid state),
                                                then I'd think 409 is the correct response.

                                                In truth, I am beginning to feel that no concensus is going to happen here
                                                and that the best approach (for now) is to just document the decision and
                                                move on.

                                                ---
                                                Seairth Jacobs
                                                seairth@...
                                              • S. Alexander Jacobson
                                                Yes, the echo/atom API work is in fact what started me thinking about MoST. My point is that we should not need an Atom API and a RSS API and a Wiki API and a
                                                Message 23 of 26 , Aug 5, 2003
                                                • 0 Attachment
                                                  Yes, the echo/atom API work is in fact what
                                                  started me thinking about MoST. My point is that
                                                  we should not need an Atom API and a RSS API and a
                                                  Wiki API and a RNA/Notification API and a Foo API.

                                                  If servers exposed the underlying data model in a
                                                  consistent syntactic format, e.g. XML then the
                                                  only API you would need is the API for
                                                  manipulating that syntactic model. The meaning of
                                                  changes to the model would be defined entirely by
                                                  the XML schema.

                                                  So, if you change from Atom to Pie to RSS.91 to
                                                  RSS2 to RNA to ...., the API shouldn't change.
                                                  Its always be GET/PUT/POST/DELETE against XML node
                                                  ids and you know that this is the API because the
                                                  content-type is text/XML!

                                                  My objection to ReST is precisely that:
                                                  1. there is no way to know the API a URI exposes
                                                  without out-of-band communication
                                                  -and-
                                                  2. GET/PUT/POST/DELETE have no consistent
                                                  *meaning* accross URI so API documentation ends up
                                                  being extensive.

                                                  You have 13 pages of documentation simply to
                                                  update an XML document with a well defined schema.
                                                  You are clearly a smart person. You should find it
                                                  frustrating to be spending your time writing such
                                                  a document and your should find it even more
                                                  frustrating to think about the number of
                                                  programmers who have to spend time reading and
                                                  understanding that document for your time
                                                  investment to pay-off.

                                                  If we just agreed that having content-type:
                                                  text/xml implied the GET/PUT/POST/DELETE semantics
                                                  against node ids that I described, it would save
                                                  everyone a lot of time and would fulfill the
                                                  simplicity promise that people have been looking
                                                  to ReST to deliver.

                                                  -Alex-

                                                  ___________________________________________________________________
                                                  S. Alexander Jacobson i2x Media
                                                  1-212-787-1914 voice 1-603-288-1280 fax






                                                  On Tue, 5 Aug 2003, Joe Gregorio wrote:

                                                  > Alex Jacobson wrote:
                                                  > > If we had a standard mapping between HTTP methods and underlying
                                                  > > content-types, everything would get MUCH simpler. The most useful mapping
                                                  > > would be from HTTP to XML and would probably look something like this:
                                                  > >
                                                  > > GET /myRSSblog returns an XML document.
                                                  > > POST /myRSSblog#channelId adds a new child to the XML node with that id.
                                                  > > GET /myRSSblog#itemId returns an XML node with that id
                                                  > > PUT /myRSSblog#itemId replaces the XML node with that id
                                                  > > DELETE /myRSSblog#itemId deletes the XML node with that id
                                                  > > (Style using <?xml-stylesheet type="text/xsl" href="yourstyle.xsl"?> for
                                                  > > your viewing pleasure.)
                                                  >
                                                  > Have you looked at the AtomAPI[1][2], which is part of this effort[3]?
                                                  >
                                                  > [1] http://bitworking.org/news/AtomAPI_URIs
                                                  > [2] http://bitworking.org/rfc/draft-gregorio-06.html
                                                  > [3] http://www.intertwingly.net/wiki/pie/FrontPage
                                                  >
                                                  > -joe
                                                  >
                                                  > --
                                                  > http://BitWorking.org
                                                  > http://WellFormedWeb.org
                                                  >
                                                Your message has been successfully submitted and would be delivered to recipients shortly.