Subject: polling re: Upgrade and CONNECT support

From: Scott Lawrence <[email-masked]>
Date: 01 May 2003 12:56:15 -0400

I'm attempting to determine what features of HTTP specified by RFC
2817 (Upgrade header and CONNECT method support) have been implemented
and tested with other implementations in order to discover whether or
not the spec can be advanced to Draft Standard status.

The RFC discusses these features in the context of upgrading to HTTP
over TLS, because doing so was needed by IPP, so I expect that some
features will have been done primarily in the HTTP used by IPP clients
and servers. 

However, the protocol features it describes are actually generic to
any use of Upgrade and CONNECT.  The usage of CONNECT is (we believe)
the same as that specified in the original Internet Draft by Ari
Luotonen, which was never otherwise published as an RFC.

If you are responsible for (or knowlegable regarding) a Client,
Server, or Proxy that implements Upgrade and/or CONNECT support in
some form, would you please take a moment to comment on its support of
the specific features outlined below?  

Replies to the list you're reading this on are fine - I'm on both.
Responses sent to me off list will be treated as confidential
information unless you specify otherwise - at most, the fact that an
affirmative response was received from someone will be made known
publicly, but neither the responder nor the implementation will be
identified.

Thank you for your time.

--
Scott Lawrence
  Actively seeking work
  http://skrb.org/scott/
  [ <[email-masked]> is deprecated ]

================ Origin Servers

Section     Server Feature

   4.1      Advertisement of TLS/1.0
              Server sends
                Upgrade: TLS/1.0
              in responses other than 101 (use of tokens other than
              'TLS/1.0' would also be interesting, but none are
              registered with IANA)

   3.3      Acceptance of Upgrade Request
              Server Sends
                101 Switching Protocols
                Upgrade: TLS/1.0, HTTP/1.1
                Connection: Upgrade

   4.2      Mandatory Upgrade Required
              Server Sends
                426 Upgrade Required
                Upgrade: TLS/1.0, HTTP/1.1
                Connection: Upgrade

   5.3      2xx to CONNECT request
              Client Sends on port 80 to origin server www.example.com
                CONNECT www.example.com:80 HTTP/1.1
                Host: www.example.com:80
              Server responds with a 2xx response

================ Clients

 Section    Client Feature

   5.2      CONNECT to port 443
              (ok - this is here so almost everyone can say yes to something)

   5.2      CONNECT to port 80 prior to upgrade request
              Client Sends
                CONNECT www.example.com:80 HTTP/1.1
                Host: www.example.com:80

   3.1      Requests optional switch to TLS/1.0
              Clients Sends
                GET ... HTTP/1.1
                Host: ...
                Upgrade: TLS/1.0
                Connection: Upgrade

   3.2      Probes for support of switch to TLS/1.0 prior to actual request
              Client Sends
                OPTIONS * HTTP/1.1
                Host: ...
                Upgrade: TLS/1.0
               Connection: Upgrade
            (the method need not be OPTIONS; any request for which an
            Upgrade is not required by the client is acceptable)

================ Proxy Servers

Section     Proxy Feature

   5.2      CONNECT to port 443

   5.2      CONNECT to port 80 prior to upgrade request
              Client Sends
                CONNECT www.example.com:80 HTTP/1.1
                Host: www.example.com:80
              Proxy establishes origin server connection, switches to
              tunnel mode and responds with some 2xx response.

   5.3      CONNECT through chained proxies
              Client Sends
                CONNECT www.example.com:80 HTTP/1.1
                Host: www.example.com:80
              Proxy Sends to next proxy toward origin server
                CONNECT www.example.com:80 HTTP/1.1
                Host: www.example.com:80
              and forwards response appropriately

---

From: Scott Lawrence <[email-masked]>
Date: 01 May 2003 14:03:17 -0400

Alex Rousskov <[email-masked]> writes:

> 	I have two comments, both from HTTP proxies point of view:
> 
> Please note that support for forwarding of 1xx responses in proxies is
> poor.

Upgrade is a hop-by-hop mechanism, so forwarding the 1xx response not
only is not required in this case, it would be broken.  The RFC has (I
think quite detailed) discussion of how to avoid problems with
proxies, so long as they fully support CONNECT.

> I believe the above are fairly well supported in decent proxies
> because they often must handle SSL/TLS tunneling (or terminating) as a
> part of the infrastructure. I know that Squid proxy cache, for
> example, supports CONNECT requests well.

The part I'm most curious about is whether or not they actually use
the port number specified in the request.  At one point (quite a while
ago now), I found that some proxies ignored it and always connected to
443.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 1 May 2003 11:53:22 -0600 (MDT)

Scott,

Please note that support for forwarding of 1xx responses in proxies is
poor. Most of the proxies we tested has violated at least one test
case related to 1xx acceptance and forwarding. For a typical example,
see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19442

While tested vendors are fixing these now-known problems, it will take
a while for changes to be implemented and to propagate. Poor support
in intermediaries means that even compliant clients and servers will
not be able to work in many real-world environments if they rely on
1xx responses.

HTH,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: Michael Sweet <[email-masked]>
Date: Thu, 1 May 2003 13:32:53 -0400 (EDT)

> publicly, but neither the responder nor the implementation will be

CUPS (http://www.cups.org/) implements HTTP Upgrade for TLS on
the client and server ends.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com