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

if-match condition and no resource found

Expand Messages
  • Thierry
    Hello, I have a question about the if-match header. As a client, I would like to PUT a new representation of a resource that I get in the past with entity tag
    Message 1 of 7 , Feb 1, 2007
    • 0 Attachment
      Hello,

      I have a question about the if-match header.
      As a client, I would like to PUT a new representation of a resource
      that I get in the past with entity tag "A". Therefore, I send a PUT
      request with the "if-match" header.
      Unfortunately, this resource has been deleted. What could be the
      behaviour of the server ?
      Here is an excerpt of the HTTP rfc 2616 :
      If none of the entity tags match, or if "*" is given and no current
      entity exists, the server MUST NOT perform the requested method".

      It could be understood in 2 ways :
      - PUT the new representation because "*" has not been given
      - send 412 status because "If none of the entity tags match" may say
      that effectively the "A" entity tag has been matched.

      Best regards,
      Thierry Boileau
    • Jon Hanna
      ... 412 because the If-Match has failed. At the client you know that this 412 means one of the following: 1. The resource was changed and hence has a different
      Message 2 of 7 , Feb 1, 2007
      • 0 Attachment
        Thierry wrote:
        > Hello,
        >
        > I have a question about the if-match header.
        > As a client, I would like to PUT a new representation of a resource
        > that I get in the past with entity tag "A". Therefore, I send a PUT
        > request with the "if-match" header.
        > Unfortunately, this resource has been deleted. What could be the
        > behaviour of the server ?

        412 because the If-Match has failed.

        At the client you know that this 412 means one of the following:

        1. The resource was changed and hence has a different entity-tag.
        2. The resource was deleted.
        3. Another precondition failed.

        Assuming there were no other preconditions (if there are then this is
        due to something your client is doing, and hence the extra complexity is
        coming from your application domain rather than the spec, anyway it's
        out of scope for the If-Match matter), then a GET on the URI will return
        one of:

        1. A 301 response because the old resources was moved. Deal with this as
        appropriate.
        2. A 2xx response with a new entity representing the resource with a new
        E-Tag. Deal with this as appropriate (most likely warning the user that
        they are going to over-write changes and asking how they would like to
        proceed).
        3. A 404 or 410 response indicating the deletion that happened in your
        hypothetical example (but which we cannot assume happened). Deal with
        this as appropriate (most likely either retrying the PUT without an
        If-Match or else warning the user about the deletion and asking how they
        would like to proceed).
        4. A 5xx or a 4xx (other than 404 or 410) response indicating an error.
      • Alan Dean
        412 Precondition Failed I have published my interpretation of the HTTP spec regarding header resolution at
        Message 3 of 7 , Feb 1, 2007
        • 0 Attachment
          412 Precondition Failed

          I have published my interpretation of the HTTP spec regarding header
          resolution at
          http://thoughtpad.net/who/alan-dean/image/http-headers-status

          Regards,
          Alan Dean

          On 2/1/07, Thierry <thboileau@...> wrote:
          >
          > I have a question about the if-match header.
          > As a client, I would like to PUT a new representation of a resource
          > that I get in the past with entity tag "A". Therefore, I send a PUT
          > request with the "if-match" header.
          > Unfortunately, this resource has been deleted. What could be the
          > behaviour of the server ?
          > Here is an excerpt of the HTTP rfc 2616 :
          > If none of the entity tags match, or if "*" is given and no current
          > entity exists, the server MUST NOT perform the requested method".
        • Alan Dean
          Thierry, Thank you for your kind comments. I am based my interpreation of the handling of If-Match: * where a resource does not exist on the following
          Message 4 of 7 , Feb 1, 2007
          • 0 Attachment
            Thierry,

            Thank you for your kind comments.

            I am based my interpreation of the handling of "If-Match: *" where a
            resource does not exist on the following paragraph:

            "The meaning of "If-Match: *" is that the method SHOULD be performed
            if the representation selected by the origin server [...] exists, and
            MUST NOT be performed if the representation does not exist."

            from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24

            Unfortunately, the spec seems to treat this header value as a special
            case - it does not specify what to do given any other conditional
            header when the resource is missing. I therefore took this to mean
            that any other conditional header has no effect when the resource is
            missing.

            This is simply my interpretation, of course, and would like to hear
            the opinions of others. If an alternative interpretation gathers a
            consensus then I will amend the diagram.

            Regards,
            Alan Dean

            On 2/1/07, Thierry Boileau <thboileau@...> wrote:
            > Hello Alan,
            >
            > First, I have to thank you for your great effort providing this so
            > comprehensive activity diagram. This is really great!
            >
            > However, I have one question about the case where no resource is found,
            > but an "If-match" header has been provided.
            > If I understand your diagram, you expect a 412 status [precondition
            > failed] when no resource exists and if and only if the "If-match"
            > header's value equals to "*".
            > I was not sure myself, therefore I've checked the HTTP RFC (which is not
            > really clear), and finally posted a mail to the "REST discuss" yahoo groups.
            > It seems that the test is : when no resource exists and if an "If-match"
            > header has been provided (not only "*").
            >
            > What are you tinking about?
            > Best regards,
            > Thierry Boileau
          • Jon Hanna
            ... It does indeed treat this value as a special case, though when you consider as a wild card it s specialness is reduced. The spec *does* specify what to
            Message 5 of 7 , Feb 1, 2007
            • 0 Attachment
              Alan Dean wrote:
              > Unfortunately, the spec seems to treat this header value as a special
              > case - it does not specify what to do given any other conditional
              > header when the resource is missing.

              It does indeed treat this value as a special case, though when you
              consider as a wild card it's "specialness" is reduced.

              The spec *does* specify what to do when the resource is missing, but not
              as explicitly.

              Consider If-Match: "abcde" when the resource is missing.

              Does this match an available resource? The answer is clearly "no".

              Now, when we consider the other rule about "If the request would,
              without the If-Match header field, result in anything other than a 2xx
              or 412 status, then the If-Match header MUST be ignored." this means
              that if the request is GET we will get a 404, but with PUT we will get a
              412 (I'm simplifying my assuming that there are no other factors
              affecting the status code returned).
            • Alan Dean
              ... If I understand your contention correctly, you are saying that: If the resource is missing; and any value at all is specified in If-Match then return 412
              Message 6 of 7 , Feb 1, 2007
              • 0 Attachment
                On 2/1/07, Jon Hanna <jon@...> wrote:
                >
                > Alan Dean wrote:
                > > Unfortunately, the spec seems to treat this header value as a special
                > > case - it does not specify what to do given any other conditional
                > > header when the resource is missing.
                >
                > It does indeed treat this value as a special case, though when you
                > consider as a wild card it's "specialness" is reduced.
                >
                > The spec *does* specify what to do when the resource is missing, but not
                > as explicitly.
                >
                > Consider If-Match: "abcde" when the resource is missing.
                >
                > Does this match an available resource? The answer is clearly "no".
                >
                > Now, when we consider the other rule about "If the request would,
                > without the If-Match header field, result in anything other than a 2xx
                > or 412 status, then the If-Match header MUST be ignored." this means
                > that if the request is GET we will get a 404, but with PUT we will get a
                > 412 (I'm simplifying my assuming that there are no other factors
                > affecting the status code returned).

                If I understand your contention correctly, you are saying that:

                If the resource is missing;
                and any value at all is specified in If-Match
                then return 412 Precondition Failed

                I can see the logic of how you reached that conclusion, but I am left
                wondering "if that is the case, why does the spec bother to stipulate
                the case of the wildcard - why not stipulate 'any' instead?"

                Hmmmmm.....

                Alan
              • Jon Hanna
                ... Nope. If the resource is missing and any value at all is specified in If-Match and request would otherwise result in 2xx result the 412 Precondition
                Message 7 of 7 , Feb 1, 2007
                • 0 Attachment
                  Alan Dean wrote:
                  > If I understand your contention correctly, you are saying that:
                  >
                  > If the resource is missing;
                  > and any value at all is specified in If-Match
                  > then return 412 Precondition Failed

                  Nope.

                  If the resource is missing
                  and any value at all is specified in If-Match
                  and request would otherwise result in 2xx result
                  the 412 Precondition Failed.

                  > I can see the logic of how you reached that conclusion, but I am left
                  > wondering "if that is the case, why does the spec bother to stipulate
                  > the case of the wildcard - why not stipulate 'any' instead?"

                  Because that's the only condition underwhich * causes a 412.

                  If-Match: "abcde" can also cause a 412 if there is an entity to return,
                  but none with that E-tag OR if there is no entity at all.

                  If-Match: * can *only* cause a 412 if there is no entity to return.
                Your message has been successfully submitted and would be delivered to recipients shortly.