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

Variant-IDs and Entity Tags (was Re: HTTP 1.1 document terminology.)

Expand Messages
  • Jeffrey Mogul
    ... Likewise, the above is incorrect entity tag A string associated with an entity and used to distinguish it from other entities of the requested resource. A
    Message 1 of 19 , May 1, 1996
    • 0 Attachment
      Roy writes:
      > entity tag
      >
      > An opaque string associated with an entity and used to distinguish it
      > from other instances of the same resource entity. A "strong entity
      > tag" is one that may be shared by two entities of a resource entity
      > only if they are equivalent by octet equality. A "weak entity tag" is
      > one that may be shared by two entities of a resource entity if they
      > are semantically equivalent. A given entity tag value may be used for
      > entities identified by two different URIs, or by the same URI and two
      > different variant-IDs, without implying anything about the equivalence
      > of these entities.

      Likewise, the above is incorrect

      entity tag
      A string associated with an entity and used to distinguish it
      from other entities of the requested resource. A "strong entity tag"
      is one that may be shared by two entities of a resource only if they
      are equivalent by octet equality. A "weak entity tag" is
      one that may be shared by two or more entities of a resource if they
      are semantically equivalent. A given entity tag value may be used for
      entities obtained by requests on different URIs without implying
      anything about the equivalence of these entities.

      [assuming the variant-id is still part of the entity tag, which it must
      be if we are going to allow variant-ids at all].

      Your assumption is wrong, but it's perhaps understandable why you
      made it.

      Originally, the variant-ID proposal was for a distinct response
      header, e.g.:
      Variant-ID: "foo"
      I believe that Koen actually made the first such proposal, and then
      I elaborated it with the variant-set mechanism later on. Since some
      people objected to this as "unnecessary", and some people were acting
      aghast at each and every proposed new field-name, at some point I
      realized that the variant-ID could be piggybacked in the (old) CVal:
      header, along with the entity-tag (aka opaque validator), since
      variant-IDs were only useful in conjunction with a cache validator.
      This was done purely to avoid defining another response header.

      In other words, the variant-ID was never part of the cache validator
      (entity tag), it was just carried in the same header for reasons
      of expendiency.

      The grammar I wrote for CVal made this implicit

      CVal = "CVal" ":" cval-info

      cval-info = opaque-validator [ ";" variant-id ]

      and then (after a few examples) I immediately added the explicit
      statement:
      Note that the variant-id is not part of the opaque validator. The
      CVal: field is used to transmit a variant-id simply as a matter of
      compact representation of responses.

      This statement remains in draft-ietf-http-v11-spec-02.txt, by the way.

      If it pains or confuses you to have these two distinct values carried
      in the same response header, I'm happy to switch back to using a
      separate Variant-ID header.

      Sorry for the confusion.

      -Jeff
    • John Franks
      I still don t understand the point of having both Connection: Persistent and Connection: Keep-Alive (not to mention Connection: keep-alive, persistent ).
      Message 2 of 19 , May 1, 1996
      • 0 Attachment
        I still don't understand the point of having both Connection:
        Persistent and Connection: Keep-Alive (not to mention "Connection:
        keep-alive, persistent"). Having carefully read section E.2.5 and
        E.2.5.1 I understand that the chunked encoding may be used with
        persistent but not with keep-alive. This seems to be the only
        difference.

        Since persistent connections are one hop phenomena and every
        client/server/proxy knows whether its immediate neighbor is talking
        1.0 or 1.1, why couldn't we always use use "keep-alive" to indicate a
        persistent connection. It seems like both ends of a transaction will
        know if the chunked encoding is allowed since they know whether they
        are speaking 1.1 or later. Chunked is required for 1.1 and not
        available for 1.0. It seems redundant and obscure to code an "it's ok
        to use chunked" message in the Connection header since isn't needed
        anyway.

        Is there something I am missing here?



        John Franks Dept of Math. Northwestern University
        john@...
      • Roy T. Fielding
        ... No, it was done because I proposed the VID (later changed to EID) header field which accomplished the exact same functionality with two fewer header fields
        Message 3 of 19 , May 2, 1996
        • 0 Attachment
          > entity tag
          > A string associated with an entity and used to distinguish it
          > from other entities of the requested resource. A "strong entity tag"
          > is one that may be shared by two entities of a resource only if they
          > are equivalent by octet equality. A "weak entity tag" is
          > one that may be shared by two or more entities of a resource if they
          > are semantically equivalent. A given entity tag value may be used for
          > entities obtained by requests on different URIs without implying
          > anything about the equivalence of these entities.
          >
          > [assuming the variant-id is still part of the entity tag, which it must
          > be if we are going to allow variant-ids at all].
          >
          > Your assumption is wrong, but it's perhaps understandable why you
          > made it.
          >
          > Originally, the variant-ID proposal was for a distinct response
          > header, e.g.:
          > Variant-ID: "foo"
          > I believe that Koen actually made the first such proposal, and then
          > I elaborated it with the variant-set mechanism later on. Since some
          > people objected to this as "unnecessary", and some people were acting
          > aghast at each and every proposed new field-name, at some point I
          > realized that the variant-ID could be piggybacked in the (old) CVal:
          > header, along with the entity-tag (aka opaque validator), since
          > variant-IDs were only useful in conjunction with a cache validator.
          > This was done purely to avoid defining another response header.

          No, it was done because I proposed the VID (later changed to EID)
          header field which accomplished the exact same functionality with two
          fewer header fields and a much simpler explanation, and was applicable
          to both caching and collaborative authoring. I never accepted the
          CVal header field as desirable, and it should never have been added to
          the specification. I expected to see the EID header field, as I defined
          it, or nothing at all in draft 02 related to validators, and certainly
          not something which was clearly unacceptable from the very beginning.

          I am not at all surprised to see that this has just perpetuated the
          confusion. An entity tag must include the variant-id if it is indeed
          an entity tag, since the variant-id is part of what discriminates
          between different entities of the same requested resource, which is
          the purpose of the entity tag. When it is used as a validator, the
          entity tag includes both the opaque change-indicator and the variant-id
          (if one is present), since both are necessary for the server to test
          for valididty (or sameness) of the entity that would be sent in the
          response.


          ...Roy T. Fielding
          Department of Information & Computer Science (fielding@...)
          University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
          http://www.ics.uci.edu/~fielding/
        • Roy T. Fielding
          ... The fifth paragragh of Section E.2.5 is poorly worded. Keep-Alive has no impact whatsoever on the use of chunked. Change An HTTP/1.1 server may also
          Message 4 of 19 , May 2, 1996
          • 0 Attachment
            > I still don't understand the point of having both Connection:
            > Persistent and Connection: Keep-Alive (not to mention "Connection:
            > keep-alive, persistent"). Having carefully read section E.2.5 and
            > E.2.5.1 I understand that the chunked encoding may be used with
            > persistent but not with keep-alive. This seems to be the only
            > difference.

            The fifth paragragh of Section E.2.5 is poorly worded. Keep-Alive
            has no impact whatsoever on the use of chunked. Change

            An HTTP/1.1 server may also establish persistent connections with
            HTTP/1.0 clients upon receipt of a Keep-Alive connection token.

            A persistent connection based on the Keep-Alive connection token MUST
            only use the _Content-Length_ technique for marking the ending
            boundaries of entity-bodies. It MAY use pipe-lining.

            to

            An HTTP/1.1 server may also establish persistent connections with
            HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
            However, a persistent connection with an HTTP/1.0 client cannot
            make use of the chunked transfer-coding, and therefore MUST use
            a Content-Length for marking the ending boundary of each Entity-Body.

            > Since persistent connections are one hop phenomena and every
            > client/server/proxy knows whether its immediate neighbor is talking
            > 1.0 or 1.1, why couldn't we always use use "keep-alive" to indicate a
            > persistent connection. It seems like both ends of a transaction will
            > know if the chunked encoding is allowed since they know whether they
            > are speaking 1.1 or later. Chunked is required for 1.1 and not
            > available for 1.0. It seems redundant and obscure to code an "it's ok
            > to use chunked" message in the Connection header since isn't needed
            > anyway.
            >
            > Is there something I am missing here?

            The fear was that some existing 1.0 clients may be sending keep-alive
            to a proxy server that doesn't understand Connection, which would then
            erroneously forward it to the next inbound server, which would establish
            the keep-alive connection and result in a dead 1.0 proxy waiting for the
            close on the response. The result is that 1.0 clients must be prevented
            from using keep-alive when talking to proxies.

            However, talking to proxies is the most important use of persistent
            connections, so that is clearly unacceptable. Therefore, we need some
            other mechanism for indicating a persistent connection is desired, which is
            safe to use even when talking to an old proxy that ignores Connection.
            As it turns out, there are two ways to accomplish that:

            1) Introduce a new keyword (persist) which is declared to be valid
            only when received from an HTTP/1.1 message.

            2) Declare persistence to be the default for HTTP/1.1 messages and
            introduce a new keyword (close) for declaring non-persistence.

            [Jim, it might be useful to insert this into the keep-alive appendix as
            rationale.]

            I am inclined to go with the second option, since it gives us a better
            migration path for future versions of the protocol and makes it easier
            for us to eventually stop supporting some of the broken implementations
            of keep-alive in existing practice.


            ...Roy T. Fielding
            Department of Information & Computer Science (fielding@...)
            University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
            http://www.ics.uci.edu/~fielding/
          • Dave Kristol
            ... Actually, despite what the spec. says, I would assume you can used chunked if the client says HTTP/1.1, whether keep-alive or persist . ... If so, I m
            Message 5 of 19 , May 2, 1996
            • 0 Attachment
              John Franks <john@...> wrote:
              > I still don't understand the point of having both Connection:
              > Persistent and Connection: Keep-Alive (not to mention "Connection:
              > keep-alive, persistent"). Having carefully read section E.2.5 and
              > E.2.5.1 I understand that the chunked encoding may be used with
              > persistent but not with keep-alive. This seems to be the only
              > difference.
              Actually, despite what the spec. says, I would assume you can used
              chunked if the client says HTTP/1.1, whether "keep-alive" or
              "persist".
              >
              > Since persistent connections are one hop phenomena and every
              > client/server/proxy knows whether its immediate neighbor is talking
              > 1.0 or 1.1, why couldn't we always use use "keep-alive" to indicate a
              > persistent connection. It seems like both ends of a transaction will
              > know if the chunked encoding is allowed since they know whether they
              > are speaking 1.1 or later. Chunked is required for 1.1 and not
              > available for 1.0. It seems redundant and obscure to code an "it's ok
              > to use chunked" message in the Connection header since isn't needed
              > anyway.
              >
              > Is there something I am missing here?

              If so, I'm missing it, too. I just spent 1/2 hour or so trying to
              write up a message explaining why we need Persist, only to reach John's
              conclusion. Either Persist is unnecessary, or the spec. needs a better
              explanation/justification.

              Dave Kristol
            • Daniel DuBois
              ... Another option would be to define a rule for client like: Send Connection: keep-alive to origin servers, and Connection: persist with a Presist:
              Message 6 of 19 , May 8, 1996
              • 0 Attachment
                At 02:50 AM 5/2/96 -0700, Roy T. Fielding wrote:
                >> I still don't understand the point of having both Connection:
                >> Persistent and Connection: Keep-Alive (not to mention "Connection:

                >The fear was that some existing 1.0 clients may be sending keep-alive
                >to a proxy server that doesn't understand Connection, which would then
                >erroneously forward it to the next inbound server, which would establish
                >the keep-alive connection and result in a dead 1.0 proxy waiting for the
                >close on the response. The result is that 1.0 clients must be prevented
                >from using keep-alive when talking to proxies.
                >[...]
                > 1) Introduce a new keyword (persist) which is declared to be valid
                > only when received from an HTTP/1.1 message.

                Another option would be to define a rule for client like:

                "Send 'Connection: keep-alive' to origin servers, and 'Connection: persist'
                with a 'Presist: <hostname>' to proxies"

                Then 1.0 servers could still do persistent connections with 1.1 clients
                without being upgraded. And no version number-specific logic is necessary.

                I have not heard of ANY 1.0 client sending Connection: headers to proxies
                (except internal builds here at Spyglass where we first encountered the dead
                proxy bug), so I think the above is a safe thing to do.

                -----
                the Programmer formerly known as Dan
                http://www.spyglass.com/~ddubois/
              • MESSAGE AGENT
                This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. The following is a prerecorded message, sent for
                Message 7 of 19 , May 8, 1996
                • 0 Attachment
                  This is an automatic reply. Feel free to send additional
                  mail, as only this one notice will be generated. The following
                  is a prerecorded message, sent for fielding


                  I'll be in Paris (WWW5 Conference) until May 12th.
                  I won't be able to answer mail until I get back.

                  ...Roy T. Fielding
                  Department of Information & Computer Science (fielding@...)
                  University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
                  http://www.ics.uci.edu/~fielding/
                Your message has been successfully submitted and would be delivered to recipients shortly.