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

HTTP/1.1 Conditional GET

Expand Messages
  • chris_pressey
    Hi, I m writing a minimal HTTP/1.1 origin server and I m striving for conditional compliance. I have a couple of newbie questions about whether Conditional GET
    Message 1 of 7 , Jun 2, 2003
    • 0 Attachment
      Hi,

      I'm writing a minimal HTTP/1.1 origin server and I'm striving for
      conditional compliance.

      I have a couple of newbie questions about whether Conditional GET
      (and Partial GET) are required or merely recommended.

      5.1.1 of RFC 2616 says:

      "...if the above methods are implemented, they MUST be implemented
      with the same semantics as those specified in section 9."

      While 9.3 says:

      "The semantics of the GET method change to a "conditional GET" if the
      request message includes an If-Modified-Since, If-Unmodified-Since,
      If-Match, If-None-Match, or If-Range header field. A conditional GET
      method requests that the entity be transferred only under the
      circumstances described by the conditional header field(s)."

      This implies to me that HTTP/1.1 origin servers MUST implement
      Conditional GET.

      However, 3.3.1 states:

      "HTTP/1.1 clients and servers that parse the date value MUST accept
      all three formats..."

      This implies to me that there can be HTTP/1.1 origin servers that do
      not parse dates, and, since parsing dates is required for Conditional
      GET, implies that they do not support Conditional GET.

      Similarly for Partial GET, 9.3 says:

      "The semantics of the GET method change to a "partial GET" if the
      request message includes a Range header field."

      Whereas 14.35.2 says:

      "A server MAY ignore the Range header."

      At the moment I figure I've misinterpreted "the above methods" in
      5.1.1 to mean all methods, when it really means all methods except
      GET and HEAD - but I'd like confirmation on this.

      Also - if Conditional GET and Partial GET are indeed optional, what
      is the most graceful way to handle these requests: just ignore the
      If-Match, Range, etc. headers and respond as if it were a plain GET?

      Thanks in advance,
      -Chris
    • Alex Rousskov
      ... There is no clear/single MUST that says the server MUST support a conditional or partial GET , I think. However, you may still get a practical answer to
      Message 2 of 7 , Jun 2, 2003
      • 0 Attachment
        On Mon, 2 Jun 2003, chris_pressey wrote:

        > I'm writing a minimal HTTP/1.1 origin server and I'm striving for
        > conditional compliance.
        >
        > I have a couple of newbie questions about whether Conditional GET
        > (and Partial GET) are required or merely recommended.

        There is no clear/single MUST that says "the server MUST support a
        conditional or partial GET", I think. However, you may still get a
        practical answer to your questions. I would just recommend looking at
        the problem from a different point of view:

        * Returning 412s for mismatched If-Match is a MUST (14.24).
        Thus, you cannot ignore If-Match.

        * Returning 304s for matching If-Modified-Since is a
        SHOULD (Section 14.25). Thus, you can ignore
        If-Modified-Since in this context.

        * Returning 200s/304s for matching If-None-Match is
        a MUST (14.26). Thus, you cannot ignore If-None-Match.

        * If-Range MUST be ignored if the server does not
        support the sub-range operation (14.27). Thus, you
        can ignore If-Range. (Same for Range, BTW).

        * Returning 412s for mismatching If-Unmodified-Since
        is a MUST (14.28). Thus, you cannot ignore
        If-Unmodified-Since.

        * Returning 304s for mismatching If-Modified-Since
        while other If-* headers match is a MUST NOT (13.3.4).
        Thus, you cannot ignore If-Modified-Since if other
        conditional headers are present. This rule probably
        excludes If-Range since there is a more specific
        MUST that says you can ignore it.

        At this point, we can conclude that you can ignore If-Range, but must
        support/recognize/honor all other If-* headers if you want to be
        conditionally compliant in all cases. However, you can return 200 OK
        responses to matching If-Modified-Since requests as long as those
        requests do not contain other If-* headers.

        HTH,

        Alex.

        --
        | HTTP performance - Web Polygraph benchmark
        www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
        | all of the above - PolyBox appliance
      • chris_pressey
        ... at ... must ... Thanks for your reply. Two of my primary design goals are conditional compliance and simplicity, so I d like to be able to reduce this
        Message 3 of 7 , Jun 4, 2003
        • 0 Attachment
          --- In http-compliance@yahoogroups.com, Alex Rousskov <rousskov@m...>
          wrote:
          > There is no clear/single MUST that says "the server MUST support a
          > conditional or partial GET", I think. However, you may still get a
          > practical answer to your questions. I would just recommend looking
          at
          > the problem from a different point of view:
          >
          > * Returning 412s for mismatched If-Match is a MUST (14.24).
          > Thus, you cannot ignore If-Match.
          >
          > * Returning 304s for matching If-Modified-Since is a
          > SHOULD (Section 14.25). Thus, you can ignore
          > If-Modified-Since in this context.
          >
          > * Returning 200s/304s for matching If-None-Match is
          > a MUST (14.26). Thus, you cannot ignore If-None-Match.
          >
          > * If-Range MUST be ignored if the server does not
          > support the sub-range operation (14.27). Thus, you
          > can ignore If-Range. (Same for Range, BTW).
          >
          > * Returning 412s for mismatching If-Unmodified-Since
          > is a MUST (14.28). Thus, you cannot ignore
          > If-Unmodified-Since.
          >
          > * Returning 304s for mismatching If-Modified-Since
          > while other If-* headers match is a MUST NOT (13.3.4).
          > Thus, you cannot ignore If-Modified-Since if other
          > conditional headers are present. This rule probably
          > excludes If-Range since there is a more specific
          > MUST that says you can ignore it.
          >
          > At this point, we can conclude that you can ignore If-Range, but
          must
          > support/recognize/honor all other If-* headers if you want to be
          > conditionally compliant in all cases. However, you can return 200 OK
          > responses to matching If-Modified-Since requests as long as those
          > requests do not contain other If-* headers.
          >
          > HTH,
          >
          > Alex.

          Thanks for your reply.

          Two of my primary design goals are conditional compliance and
          simplicity, so I'd like to be able to reduce this problem to an
          absolute, yet practical, minimum. This brings me to a followup
          question.

          I have not yet seen a clear MUST in regard to generating and sending
          ETags. The closest I have seen are:

          - "An entity tag MUST be unique across all versions of all entities
          associated with a particular resource." (3.11)
          - "Servers MUST NOT depend on clients being able to choose
          deterministically between responses generated during the same second"
          (13.2)

          On the assumption that it is optional for an origin server to
          generate ETags, would it also be acceptable to assume that:
          - any request with only If-Match will always return 412
          - any request with only If-None-Match will never return 412
          ...since a client which sends my server any entity tags is obviously
          confused (since it couldn't have got them from my server! :)

          If this is the case it would greatly simplify my server; I would
          still have to add code to parse dates to satisfy If-Unmodified-Since
          (and at that point I might as well implement If-Modified-Since too,
          since it's a near-trivial variation on If-Unmodified-Since), but the
          logic for handling If-[None-]Match would remain minimal.

          On the other hand, if ETags are a MUST, I suppose I will have to
          consider the simplest way to generate them, first.

          Thanks again for your time.
          -Chris
        • Alex Rousskov
          ... Except for If-Match: * ... Except for If-None-Match: * especially for non-GET/HEAD methods. ... In general, your server may be serving content that was
          Message 4 of 7 , Jun 4, 2003
          • 0 Attachment
            On Wed, 4 Jun 2003, chris_pressey wrote:

            > On the assumption that it is optional for an origin server to
            > generate ETags, would it also be acceptable to assume that:
            >
            > - any request with only If-Match will always return 412

            Except for
            If-Match: *

            > - any request with only If-None-Match will never return 412

            Except for
            If-None-Match: *
            especially for non-GET/HEAD methods.

            > ...since a client which sends my server any entity tags is obviously
            > confused (since it couldn't have got them from my server! :)

            In general, your server may be serving content that was previously
            served by an ETag-generating server, explaining now-stale e-tags in
            request headers; so the client is not necessarily "confused". The "*"
            case is used to make PUTs and such safer.

            Also be careful with If-Range if you are going to support ranges,
            because If-Range can use HTTP-date as a validator (section 14.27) so
            you cannot ignore it even if you generate no entity-tags.

            > If this is the case it would greatly simplify my server; I would
            > still have to add code to parse dates to satisfy If-Unmodified-Since
            > (and at that point I might as well implement If-Modified-Since too,
            > since it's a near-trivial variation on If-Unmodified-Since), but the
            > logic for handling If-[None-]Match would remain minimal.

            The logic behind all If-* headers is not that complex after you digest
            RFC wording into something more systematic/algorithmic (which may take
            days). The core of it can be expressed in less than 100 lines of code.
            Nevertheless, if you can bypass all e-tag operations, your code will
            be simpler, of course.

            > On the other hand, if ETags are a MUST, I suppose I will have to
            > consider the simplest way to generate them, first.

            Generating ETags is optional.

            Alex.

            --
            | HTTP performance - Web Polygraph benchmark
            www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
            | all of the above - PolyBox appliance
          • chris_pressey
            ... Thanks for all the pointers. I ll make sure to include your name in the credits under compliancy help . :) -Chris
            Message 5 of 7 , Jun 28, 2003
            • 0 Attachment
              --- In http-compliance@yahoogroups.com, Alex Rousskov <rousskov@m...>
              wrote:
              >
              > On Wed, 4 Jun 2003, chris_pressey wrote:
              >
              > > On the assumption that it is optional for an origin server to
              > > generate ETags, would it also be acceptable to assume that:
              > >
              > > - any request with only If-Match will always return 412
              >
              > Except for
              > If-Match: *
              > [...]
              > > On the other hand, if ETags are a MUST, I suppose I will have to
              > > consider the simplest way to generate them, first.
              >
              > Generating ETags is optional.

              Thanks for all the pointers. I'll make sure to include your name in
              the credits under "compliancy help". :)

              -Chris
            • Chris Pressey
              Hello again, ... Well, it took me a little longer than days :) (Actually, I just hadn t had time to work on it over the summer.) I think I have come up with an
              Message 6 of 7 , Sep 30, 2003
              • 0 Attachment
                Hello again,

                --- Alex Rousskov <rousskov@...> wrote:
                > The logic behind all If-* headers is not that complex after you
                > digest RFC wording into something more systematic/algorithmic
                > (which may take days).

                Well, it took me a little longer than days :)
                (Actually, I just hadn't had time to work on it over the summer.)

                I think I have come up with an absolutely minimal logic for an
                origin server reacting to If-* headers that remains conditionally
                compliant with RFC 2616, but I would appreciate a sanity check.

                The pseudocode is:


                if If-Match is present and it is not "*"
                respond with 412 Precondition Failed
                if If-None-Match is "*"
                begin
                if the request method is neither "GET" nor "HEAD"
                respond with 412 Precondition Failed
                if neither If-Modified-Since nor If-Unmodified-Since is present
                respond with 501 Not Implemented
                end
                otherwise respond with the requested resource


                I fully admit that the primary goal is for the code to be
                minimal; specifically, I don't want to have code to parse
                the date, and I want the set of possible responses to be as
                small as possible. I realize the 501 Not Implemented is a
                bit "rude", but it doesn't appear to be in violation of
                RFC 2616; the important part seems to be that I MUST NOT
                serve the requested resource if If-None-Match matches
                (i.e. in my ETag-less case, if it'd "*") in the absence of
                If-[Un]modified-Since headers.

                Unless I have missed something?

                Thanks in advance for any help.

                -Chris

                ______________________________________________________________________
                Post your free ad now! http://personals.yahoo.ca
              • Chris Pressey
                ... if If-Unmodified-Since is present respond with 412 Precondition Failed ... ...in other words, pessimistically assume the resource has changed. -Chris
                Message 7 of 7 , Oct 1, 2003
                • 0 Attachment
                  --- Chris Pressey <chris_pressey@...> wrote: > Hello again,
                  > I think I have come up with an absolutely minimal logic for an
                  > origin server reacting to If-* headers that remains conditionally
                  > compliant with RFC 2616, but I would appreciate a sanity check.
                  >
                  > The pseudocode is:

                  Oops, let me make a tiny revision:

                  > if If-Match is present and it is not "*"
                  > respond with 412 Precondition Failed
                  > if If-None-Match is "*"
                  > begin
                  > if the request method is neither "GET" nor "HEAD"
                  > respond with 412 Precondition Failed
                  > if neither If-Modified-Since nor If-Unmodified-Since is present
                  > respond with 501 Not Implemented
                  > end

                  if If-Unmodified-Since is present
                  respond with 412 Precondition Failed

                  > otherwise respond with the requested resource

                  ...in other words, pessimistically assume the resource has changed.

                  -Chris


                  ______________________________________________________________________
                  Post your free ad now! http://personals.yahoo.ca
                Your message has been successfully submitted and would be delivered to recipients shortly.