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

Re: Call for Closure - HTTP response version

Expand Messages
  • Koen Holtman
    ... ?? I think it refers to headers. ... Actually, Dave s point 2) is correct too, but it fails to mention that 1.0 clients will *also* understand responses
    Message 1 of 18 , Jan 1, 1997
    • 0 Attachment
      Alexei Kosut:
      >
      >On Tue, 31 Dec 1996, Koen Holtman wrote:
      >
      >> Dave Kristol:
      >> >
      >> >Let me make some assumptions. They may be controversial, but I haven't
      >> >seen substantial contradictory evidence:
      >> >
      >> >1) The HTTP/1.1 draft is clear about which HTTP/1.1 headers cannot be
      >> >sent to HTTP/1.0 clients.
      >> >
      >> >2) If an HTTP/1.1 server sends a response labeled as HTTP/1.1, but with
      >> >only HTTP/1.0-compatible headers, HTTP/1.0 clients will understand
      >> >it.
      >>
      >> Ugh. I don't know what twist in this thread caused you to make those
      >> assumptions, but they paint a completely wrong picture of the actual
      >> situation.
      >
      >No, I don't think that's wrong. Dave's point 2) refers more to the
      >"HTTP/1.1" label than the headers,

      ?? I think it refers to headers.

      >and point 1) is correct.

      Actually, Dave's point 2) is correct too, but it fails to mention that
      1.0 clients will *also* understand responses which include all kinds
      of headers *not* defined by HTTP/1.0.

      >There are
      >some headers that don't work with HTTP/1.0. I guess they *could* be
      >sent... but page 23 does say "A server MUST NOT send transfer-codings
      >to an HTTP/1.0 client," for example.

      A transfer encoding is an encoding of the message body, it is not a
      header. Even AOL's proxy did not break on the presence of a HTTP/1.1
      header. It broke on the the presence of the HTTP/1.1 version number.

      >Alexei Kosut

      Koen.
    • Koen Holtman
      ... [...] ... I see no such overloading in the HTTP/1.1 spec. The spec is clear on the fact that the minor version number in the response does 1 (but only for
      Message 2 of 18 , Jan 1, 1997
      • 0 Attachment
        David W. Morris:
        >
        [...]
        >Another choice is to stop overloading a single value for two
        >purposes ...
        > 1. Declaring the servers capabilities
        > 2. Labeling the level of the response

        I see no such overloading in the HTTP/1.1 spec. The spec is clear on
        the fact that the minor version number in the response does 1 (but
        only for this particular request!), not 2.

        Now, there *might* be a good reason to add a header which does 2. A
        header which says `this response is compatible with both 1.0 clients
        and 1.1 clients' might be useful for a 1.1 caching proxy. We'll find
        out when someone actually starts trying to build such a proxy.

        >Dave Morris

        Koen.
      • Koen Holtman
        ... If a 1.0 proxy forwards a request and gets back a 1.1 response, it is allowed to switch to tunnel behavior and forward the exact response to the client,
        Message 3 of 18 , Jan 1, 1997
        • 0 Attachment
          David W. Morris:
          >
          >A data point ...
          >
          >I have just observed that the CERN 3.0 proxy forwards the response
          >status from the server to the client.
          >
          > client sent HTTP/1.0
          > client gets back HTTP/1.1 in what would clearly seem to be a non-1.1
          > proxy context.

          If a 1.0 proxy forwards a request and gets back a 1.1 response, it is
          allowed to switch to tunnel behavior and forward the exact response to
          the client, 1.1 version number included. So what you have seen need
          not be a bug in the CERN 3.0 proxy, it may be the CERN 3.0 proxy
          switching to tunnel behavior.

          On the other hand, if you are sure you are getting the 1.1 response
          from CERN proxy cache memory, without the origin server being
          contacted, then there _is_ a bug in the CERN 3.0 proxy. Does the Date
          header change in subsequent responses?

          >Dave Morris

          Koen.
        Your message has been successfully submitted and would be delivered to recipients shortly.