Re: proxying non HTTP protocols through HTTP

Wouldn't the Upgrade header help out with this
===
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42
The Upgrade general-header allows the client to specify what additional
communication protocols it supports and would like to use if the server
finds it appropriate to switch protocols. The server MUST use the Upgrade
header field within a 101 (Switching Protocols) response to indicate which
protocol(s) are being switched.
       Upgrade        = "Upgrade" ":" 1#product
For example,

       Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism for
transition from HTTP/1.1 to some other, incompatible protocol. It does so by
allowing the client to advertise its desire to use another protocol, such as
a later version of HTTP with a higher major version number, even though the
current request has been made using HTTP/1.1. This eases the difficult
transition between incompatible protocols by allowing the client to initiate
a request in the more commonly supported protocol while indicating to the
server that it would like to use a "better" protocol if available (where
"better" is determined by the server, possibly according to the nature of
the method and/or resource being requested).

The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer connection. Upgrade cannot be
used to insist on a protocol change; its acceptance and use by the server is
optional. The capabilities and nature of the application-layer communication
after the protocol change is entirely dependent upon the new protocol
chosen, although the first action after changing the protocol MUST be a
response to the initial HTTP request containing the Upgrade header field.

[...]



----- Original Message ----- 
From: "Salvador Fandiņo" <sfandino@ya.com>
To: <www-talk@w3.org>
Sent: Thursday, June 05, 2003 7:41 AM
Subject: proxying non HTTP protocols through HTTP


>
> Hi,
>
> I have been working on an HTTP proxy that using different
> techniques can improve the transmission ratios over slow lines
> for web traffic. Now I want to do the same for other protocols
> like IMAP, SMTP or NNTP but I have found that there is not any
> standard defining how to proxy them.
>
> Well, there is SOCKS 4/5 but it is not an application layer
> proxy. SOCKS allows to forward TCP and UDP connections but there
> is not any way to know which protocols are being talked over the
> connections unless some heuristics are applied, and heuristics
> can fail.
>
> Looking at HTTP, the CONNECT method also allows for proxying any
> protocol but it has the same problem that SOCKS: there is not
> information about which protocol is being used. The difference is
> that headers can be used for that.
>
> So my intention with this mail is to start a discussion about how
> to extend HTTP to support proxying at the application layer of
> non-HTTP protocols in this way:
>
>    1- connect to proxy
>    2- use HTTP to request a new connection talking protocol P
>    3- switch to protocol P
>    4- talk P
>    5- close connection
>
> The important point and the one that needs to be defined is 2,
> how to tell the proxy whith protocol to use. I have some ideas
> about that and I hope I will be able to expose them better with
> some example HTTP requests:
>
>
> 1) Using "CONNECT" and "Upgrade" header:
>
>    CONNECT my.imap.server.com HTTP/1.1
>    Upgrade: IMAP
>    Connection: Upgrade
>
>
> 2) Using "CONNECT" with new header (i.e. "New-Protocol")
>
>    CONNECT my.imap.server.com HTTP/1.1
>    New-Protocol: IMAP
>
>
> 3) add a new HTTP method for proxying:
>
>    PROXY imap:my.imap.server.com HTTP/1.1
>
>
> 4) Adding protocol specification to host:
>
>    CONNECT imap:my.imap.server.com HTTP/1.1
>
>
> BTW, my preferred option is the first one that reuses elements
> already existent on the HTTP protocol.
>
> Other point needing consideration is what happens when several
> proxies are chained. "Upgrade" is a one hop header.
>
>
>
> I am awaiting your comments,
>
> Best Regards,
>
>    - Salvador Fandiņo.
>
>
>
>
>

Received on Friday, 6 June 2003 00:13:40 UTC