On Mon, 24 Nov 2008, Bharat Varma wrote:

> If I understand this correctly, the whole idea behind this is based on
> luotonen web proxy tunneling RFC (which got expired in 1999) which is also
> referred to in RFC 2817.

It is also referred to in RFC2616 but the lack of a formal RFC for this (HTTP
CONNECT method) is in fact rather interesting. But then I figure it follows
the trend in lots of this web-related stuff: we don't need RFCs we just do
what the others have already done (and apply our own interpretations)... :)

> My question is, can this idea be used in production ?

There are a whole world out there using CONNECT through HTTP proxies so the
support for it won't go away and the method on how it is done won't change
within many years. It's just so widely established it is next to carved in
stone by now.

I won't guarantee this of course, but it is my assumption.

> Assuming I can guarantee that the server can listen on port 443 (i.e. It is
> my server, my client and I can decide which ports they use or connect), what
> can be the downsides of using the proxy tunnel ?

Protocol-wise there's nothing particular to mention. If it is clever for your
application and use-case I cannot tell.

> 1. Any sort of problems in proxy support ? Is there anything any proxy can
> do to invalidate this idea of a HTTP CONNECT and then a continous TCP stream
> ?

They can refuse the request.

> 2. Any other technical problems I might have overlooked ? I am assuming that
> even for authenticated proxies, I can simply give corresponding auth info
> (after I get it from the user of course) and get the tunnel up and going.

Yes you can.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html