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

HTTP 4xx response entities

Expand Messages
  • Seairth Jacobs
    Typically, entities in a 4xx response have been html messages giving details of the error. This is fine if the client is a web browser, but more or less
    Message 1 of 6 , Jul 30, 2003
    • 0 Attachment
      Typically, entities in a 4xx response have been html messages giving details
      of the error. This is fine if the client is a web browser, but more or less
      useless if the client doesn't work with html. For instance, suppose you
      have a client that GETs, POSTs, PUTs, and DELETEs XML documents. If a PUT
      fails, then an appropriate error response must be returned (e.g. 403
      Forbidden). Ideally, the response entity would given an indication of what
      went wrong and the format of the entity would be something that the client
      understood. In this case, it makes sense that the response entity would
      likely be XML since it was the content-type of the request entity.

      So, where to go from here? Is there a specification for conveying "error"
      information? If not, I would like to propose the following:

      The general format would be something like:

      <responseMetadata level="" code="">
      details
      </responseMetadata>

      "level" can be either "HTTP" or "APPLICATION". "HTTP" would be used to
      provide extended response information beyond what HTTP currently allows.
      For instance, if the response were 406 (Not Acceptable), the details could
      list the possible content-types that could be returned. "APPLICATION" would
      be used to provide extended response information about the processing
      application. For instance, when the PUT of an XML document fails due to an
      invalid value, this level would be used to indicate the failure was not at
      the HTTP level.

      Note: "realm" or "type" may be a better name than "level".

      "code" is a akin to an error number. The type of code used depends on the
      value of "level". If level="HTTP", then the code would be the same as the
      HTTP response code (e.g., if a 403 response is sent, then code="403"). If
      level="APPLICATION", then the possible values of code are
      application-specific.

      Note: Maybe for level="HTTP", the "code" would be left off, as it is
      redundant.

      The "details" would be additional markup specific to the level and code
      given. In the case of level="HTTP", this specification would be fleshed out
      to include "standard" markup for each response code (if there is any). For
      level="APPLICATION", the nature of the markup is entirely
      application-specific.

      For example:

      1) POST an "application/xml" document returns:

      HTTP/1.1 403 Forbidden
      Content-Type: application/responseMetadata+xml

      <responseMetadata level="APPLICATION" code="14">
      <!-- code="14" indicates a missing element in
      the request. In this case, "identity". -->
      <element name="identity"/>
      </responseMetadata>

      2) GET an "text/oddball" document returns:

      HTTP/1.1 406 Not Acceptable
      Content-Type: application/responseMetadata+xml

      <responseMetadata level="HTTP">
      <!-- listed in order of preference? -->
      <content-type value="text/xml"/>
      <content-type value="application/xml"/>
      <content-type value="image/gif"/>
      <content-type value="text/html"/>
      </responseMetadata>



      Additional notes:

      1) This could also be used for 5xx responses.

      2) This could technique *could* be used to respond to OPTIONS request (with
      a 200 response). For level="HTTP", additional information about the list of
      understood request headers and their possible values could be given. For
      level="APPLICATION", additional application-specific information about the
      resource could be given.

      3) Though this response could be used for requests other than POSTing and
      PUTing of XML documents, an additional level of "XML" may be provided, where
      a series of codes and detail would be provided which correspond to the
      well-formedness rules in the XML specification. Is there maybe a list like
      this already?

      At any rate, you all get the idea... what do you think?

      ---
      Seairth Jacobs
      seairth@...
    • Julian Reschke
      I think it s a good idea, but it seems you re re-inventing something that already exists in WebDAV protocols:
      Message 2 of 6 , Jul 30, 2003
      • 0 Attachment
        I think it's a good idea, but it seems you're re-inventing something that
        already exists in WebDAV protocols:

        http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6

        Note that the format doesn't do all that your proposal does, but it is
        extensible. It also avoids the issue of code collisions by marshalling XML
        error elements instead.

        --
        <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

        > -----Original Message-----
        > From: Seairth Jacobs [mailto:seairth@...]
        > Sent: Thursday, July 31, 2003 3:48 AM
        > To: rest-discuss
        > Subject: [rest-discuss] HTTP 4xx response entities
        >
        >
        > Typically, entities in a 4xx response have been html messages
        > giving details
        > of the error. This is fine if the client is a web browser, but
        > more or less
        > useless if the client doesn't work with html. For instance, suppose you
        > have a client that GETs, POSTs, PUTs, and DELETEs XML documents. If a PUT
        > fails, then an appropriate error response must be returned (e.g. 403
        > Forbidden). Ideally, the response entity would given an
        > indication of what
        > went wrong and the format of the entity would be something that the client
        > understood. In this case, it makes sense that the response entity would
        > likely be XML since it was the content-type of the request entity.
        >
        > So, where to go from here? Is there a specification for conveying "error"
        > information? If not, I would like to propose the following:
        >
        > The general format would be something like:
        >
        > <responseMetadata level="" code="">
        > details
        > </responseMetadata>
        >
        > "level" can be either "HTTP" or "APPLICATION". "HTTP" would be used to
        > provide extended response information beyond what HTTP currently allows.
        > For instance, if the response were 406 (Not Acceptable), the details could
        > list the possible content-types that could be returned.
        > "APPLICATION" would
        > be used to provide extended response information about the processing
        > application. For instance, when the PUT of an XML document fails
        > due to an
        > invalid value, this level would be used to indicate the failure was not at
        > the HTTP level.
        >
        > Note: "realm" or "type" may be a better name than "level".
        >
        > "code" is a akin to an error number. The type of code used depends on the
        > value of "level". If level="HTTP", then the code would be the same as the
        > HTTP response code (e.g., if a 403 response is sent, then code="403"). If
        > level="APPLICATION", then the possible values of code are
        > application-specific.
        >
        > Note: Maybe for level="HTTP", the "code" would be left off, as it is
        > redundant.
        >
        > The "details" would be additional markup specific to the level and code
        > given. In the case of level="HTTP", this specification would be
        > fleshed out
        > to include "standard" markup for each response code (if there is
        > any). For
        > level="APPLICATION", the nature of the markup is entirely
        > application-specific.
        >
        > For example:
        >
        > 1) POST an "application/xml" document returns:
        >
        > HTTP/1.1 403 Forbidden
        > Content-Type: application/responseMetadata+xml
        >
        > <responseMetadata level="APPLICATION" code="14">
        > <!-- code="14" indicates a missing element in
        > the request. In this case, "identity". -->
        > <element name="identity"/>
        > </responseMetadata>
        >
        > 2) GET an "text/oddball" document returns:
        >
        > HTTP/1.1 406 Not Acceptable
        > Content-Type: application/responseMetadata+xml
        >
        > <responseMetadata level="HTTP">
        > <!-- listed in order of preference? -->
        > <content-type value="text/xml"/>
        > <content-type value="application/xml"/>
        > <content-type value="image/gif"/>
        > <content-type value="text/html"/>
        > </responseMetadata>
        >
        >
        >
        > Additional notes:
        >
        > 1) This could also be used for 5xx responses.
        >
        > 2) This could technique *could* be used to respond to OPTIONS
        > request (with
        > a 200 response). For level="HTTP", additional information about
        > the list of
        > understood request headers and their possible values could be given. For
        > level="APPLICATION", additional application-specific information about the
        > resource could be given.
        >
        > 3) Though this response could be used for requests other than POSTing and
        > PUTing of XML documents, an additional level of "XML" may be
        > provided, where
        > a series of codes and detail would be provided which correspond to the
        > well-formedness rules in the XML specification. Is there maybe a
        > list like
        > this already?
        >
        > At any rate, you all get the idea... what do you think?
        >
        > ---
        > Seairth Jacobs
        > seairth@...
        >
        >
        >
        > 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/
        >
        >
      • Seairth Jacobs
        Hmm... I do see the similarities. However, I was hoping for something stand-alone. I do like the idea of using element-naming instead of the code
        Message 3 of 6 , Jul 31, 2003
        • 0 Attachment
          Hmm... I do see the similarities. However, I was hoping for something
          stand-alone. I do like the idea of using element-naming instead of the
          "code" attribute. The original example might look something like:

          <responseMetadata level="APPLICATION">
          <missingElement name="identity"/>
          </responseMetadata>

          I do not see a need for extensability here, with the possible exception of
          providing more values for "level". For instance,

          <responseMetadata level="WebDAV">
          <D:error xmlns:D="DAV:">
          <must-be-checked-in/>
          </D:error>
          </responseMetadata>

          or it could be simplified to:

          <responseMetadata level="WebDAV">
          <must-be-checked-in/>
          </responseMetadata>

          After all, the "error" bit is redundant if receiving this in a 4xx (Client
          Error) response. On the other hand, it may be that WebDAV would fall under
          the "APPLICATION" level...

          ---
          Seairth Jacobs
          seairth@...


          From: "Julian Reschke" <julian.reschke@...>
          >
          > I think it's a good idea, but it seems you're re-inventing something that
          > already exists in WebDAV protocols:
          >
          > http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6
          >
          > Note that the format doesn't do all that your proposal does, but it is
          > extensible. It also avoids the issue of code collisions by marshalling XML
          > error elements instead.
        • Julian Reschke
          ... Well, this is a RFC that is already implemented by many servers, so it s not likely to change. RFC2518bis (WebDAV RFC revision) is supposed to adopt this
          Message 4 of 6 , Jul 31, 2003
          • 0 Attachment
            > From: Seairth Jacobs [mailto:seairth@...]
            > Sent: Thursday, July 31, 2003 3:01 PM
            > To: rest-discuss
            > Subject: Re: [rest-discuss] HTTP 4xx response entities
            >
            >
            > ...
            >
            > or it could be simplified to:
            >
            > ...

            Well, this is a RFC that is already implemented by many servers, so it's not
            likely to change. RFC2518bis (WebDAV RFC revision) is supposed to adopt this
            format as well.


            --
            <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
          • Seairth Jacobs
            Yeah, I realize that. It was more of an example than a suggestion. :) However, have any other applications/specifications out there adopted this same format?
            Message 5 of 6 , Jul 31, 2003
            • 0 Attachment
              Yeah, I realize that. It was more of an example than a suggestion. :)
              However, have any other applications/specifications out there adopted this
              same format? I could certainly role something for my own use (and may still
              do so). However, I'd much rather use a common/general-purpose format
              instead of borrow one that's not intended for use outside of the
              specification in which it's defined.

              Seairth

              ----- Original Message -----
              From: "Julian Reschke" <julian.reschke@...>
              To: "Seairth Jacobs" <seairth@...>; "rest-discuss"
              <rest-discuss@yahoogroups.com>
              Sent: Thursday, July 31, 2003 10:21 AM
              Subject: RE: [rest-discuss] HTTP 4xx response entities


              > > From: Seairth Jacobs [mailto:seairth@...]
              > > Sent: Thursday, July 31, 2003 3:01 PM
              > > To: rest-discuss
              > > Subject: Re: [rest-discuss] HTTP 4xx response entities
              > >
              > >
              > > ...
              > >
              > > or it could be simplified to:
              > >
              > > ...
              >
              > Well, this is a RFC that is already implemented by many servers, so it's
              not
              > likely to change. RFC2518bis (WebDAV RFC revision) is supposed to adopt
              this
              > format as well.
              >
              >
              > --
              > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
              >
            • Julian Reschke
              Well, I d say that WebDAV and DeltaV are probably the two most visible extensions to HTTP/1.1. And there s really no reason *not* to use it outside these specs
              Message 6 of 6 , Jul 31, 2003
              • 0 Attachment
                Well,

                I'd say that WebDAV and DeltaV are probably the two most visible extensions
                to HTTP/1.1. And there's really no reason *not* to use it outside these
                specs -- it's designed to work in any "pure" HTTP environment after all...

                Julian

                --
                <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

                > -----Original Message-----
                > From: Seairth Jacobs [mailto:seairth@...]
                > Sent: Thursday, July 31, 2003 4:54 PM
                > To: rest-discuss
                > Subject: Re: [rest-discuss] HTTP 4xx response entities
                >
                >
                > Yeah, I realize that. It was more of an example than a suggestion. :)
                > However, have any other applications/specifications out there adopted this
                > same format? I could certainly role something for my own use
                > (and may still
                > do so). However, I'd much rather use a common/general-purpose format
                > instead of borrow one that's not intended for use outside of the
                > specification in which it's defined.
                >
                > Seairth
                >
                > ----- Original Message -----
                > From: "Julian Reschke" <julian.reschke@...>
                > To: "Seairth Jacobs" <seairth@...>; "rest-discuss"
                > <rest-discuss@yahoogroups.com>
                > Sent: Thursday, July 31, 2003 10:21 AM
                > Subject: RE: [rest-discuss] HTTP 4xx response entities
                >
                >
                > > > From: Seairth Jacobs [mailto:seairth@...]
                > > > Sent: Thursday, July 31, 2003 3:01 PM
                > > > To: rest-discuss
                > > > Subject: Re: [rest-discuss] HTTP 4xx response entities
                > > >
                > > >
                > > > ...
                > > >
                > > > or it could be simplified to:
                > > >
                > > > ...
                > >
                > > Well, this is a RFC that is already implemented by many servers, so it's
                > not
                > > likely to change. RFC2518bis (WebDAV RFC revision) is supposed to adopt
                > this
                > > format as well.
                > >
                > >
                > > --
                > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
                > >
                >
                >
                >
                > 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/
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.