> so e.g. a client could connect to your server (through NAT, firewalls,
> etc.; all you need is TCP) and you could start sending POST methods
> 'back' to it.
There was some discussion a while back on this list about doing just this to
'send' to behind-the-firewall resources.
The connection is initiated by the protected machine, a 'protocol upgrade'
message is sent, and after that it is regular HTTP with the protected
machine playing the role of server. A simple form of tunnelling which does
not break HTTP in any way - other than intermediaries, which shouldn't be a
concern in this situation anyway (since the alternative is a custom
protocol).

> I came across I pretty good summary of the various options.
>
> http://www.clipcode.com/peer/http_async_notif.htm
>
Yes - this is a good survey of different approaches. I'm not sure the
'never-ending response' /requires/ two connections. By the way, this is also
how KnowNow does stuff (response going to a browser has multiple events,
each is picked up by javascript on the client and dispatched to app code on
a page).

I think the 'TURN' approach is what we've talked about here - Mark or
somebody suggested the 'protocol upgrade' aspect of HTTP may be able to help
out here. ClipCode says this is 'not standard http' and recommends BEEP, but
I think the initiation is the only part not purely HTTP (and even then, it
follows the rules of extensions).

>
> ----- Original Message -----
> From: "S. Mike Dierken" <mdierken@...>
>
> ----- Original Message -----
> From: "Vincent D Murphy" <vdm@...>
>
> > so e.g. a client could connect to your server (through NAT, firewalls,
> > etc.; all you need is TCP) and you could start sending POST methods
> > 'back' to it.
> There was some discussion a while back on this list about doing just this
to
> 'send' to behind-the-firewall resources.
> The connection is initiated by the protected machine, a 'protocol upgrade'
> message is sent, and after that it is regular HTTP with the protected
> machine playing the role of server. A simple form of tunnelling which does
> not break HTTP in any way - other than intermediaries, which shouldn't be
a
> concern in this situation anyway (since the alternative is a custom
> protocol).
>

Mark Baker

... If you want to send HTTP back through HTTP, as I see it you have two choices; CONNECT or TURN. I don t believe Upgrade is suitable, because its semantics

Sorry guys, I haven t been following closely but from previous thinking I strongly believe that there is a really useful RFC potential in a simple mechanism to

Message 4 of 14
, Oct 2, 2002

0 Attachment

Sorry guys, I haven't been following closely but from previous thinking
I strongly believe that there is a really useful RFC potential in a
simple mechanism to turn around an HTTP connection. It isn't that
different than launching SSL from HTTP. http://rfc.sunsite.dk/rfc/rfc2817.html

Sorry for jumping in the middle. Wasted my email time today on TAG.

Paul Prescod

S. Mike Dierken

... From: Paul Prescod ... I think there is a lot in there that is good - but I m not sure what HTTP method we d apply the Upgrade header

> Sorry guys, I haven't been following closely but from previous thinking
> I strongly believe that there is a really useful RFC potential in a
> simple mechanism to turn around an HTTP connection. It isn't that
> different than launching SSL from HTTP.
> http://rfc.sunsite.dk/rfc/rfc2817.html
>
> Sorry for jumping in the middle. Wasted my email time today on TAG.
>

I think there is a lot in there that is good - but I'm not sure what HTTP
method we'd apply the Upgrade header to.
It is really a server operation, not a per-resource operation. I don't know
the SSL+HTTP stuff, so it might be a lot more similar that I'm thinking.

So what are the choices?
a) Upgrade header
- what method(s) or resources would this apply to? (probably OPTIONS...)
- is it sufficiently like keep-alive that is applies to multiple requests?
- am I worrying over nothing regarding Upgrade and multiple
resources/methods?

b) CONNECT method
- how would this work?
- CONNECT seems to be per-host rather than per-resource (you couldn't have
multiple resources, one per 'message queue'- but this might simplify
security/authority issues)
- what is CONNECT used for anyway? Is it for tunning a /different/ protocol
over port 80 to a destination system?

c) new method (TURN or something)

Paul Prescod

... They use OPTIONS. Why not copy? ... I think that RFC 2817 bears study. I d almost use it as a template for a new one. ... It applies to the *socket*. You

Message 6 of 14
, Oct 3, 2002

0 Attachment

S. Mike Dierken wrote:

> ----- Original Message -----
>...
>
> I think there is a lot in there that is good - but I'm not sure what HTTP
> method we'd apply the Upgrade header to.

They use OPTIONS. Why not copy?

> It is really a server operation, not a per-resource operation. I don't know
> the SSL+HTTP stuff, so it might be a lot more similar that I'm thinking.

I think that RFC 2817 bears study. I'd almost use it as a template for a
new one.

> So what are the choices?
> a) Upgrade header
> - what method(s) or resources would this apply to? (probably OPTIONS...)
> - is it sufficiently like keep-alive that is applies to multiple requests?

It applies to the *socket*. You are switching protocols from HTTP to
"Reverse HTTP" which happens to have identical syntax and semantics to
HTTP except you never create a Reverse HTTP connection directly, you
always get one by reusing an ordinary HTTP socket.

> - am I worrying over nothing regarding Upgrade and multiple
> resources/methods?
>
> b) CONNECT method
> - how would this work?
> - CONNECT seems to be per-host rather than per-resource (you couldn't have
> multiple resources, one per 'message queue'- but this might simplify
> security/authority issues)
> - what is CONNECT used for anyway? Is it for tunning a /different/ protocol
> over port 80 to a destination system?

> S. Mike Dierken wrote:
> > ----- Original Message -----
> >...
> >
> > I think there is a lot in there that is good - but I'm not sure what
HTTP
> > method we'd apply the Upgrade header to.
>
> They use OPTIONS. Why not copy?
Yes, I think that would work.

> > c) new method (TURN or something)
>
> I don't think that there is a need for it.

I think maybe a 'PROXY' method (requesting that the server begin acting as a
type of proxy) might make sense.
If CONNECT has a way to advertise what particular protocol will be
'tunnelled' - like "HTTP-Reverse/1.1" - then proxies will still be able to
participate (caching, cache purging, etc.). Although I don't really care if
proxies are involved.

I see two scenarios for this technology -
a) expose private machine on public Web
the private machine wants to be public but can't accept incoming connections
so the public machine proxies that job
Useful for dynamic IP allocation, either due to ISP allocated addresses or
through 'nomadic/mobile' use. Other approaches like dyndns.org may solve the
host/ip mapping issue, but not incoming connection issues.
This turns the client into a server - which means you need more security and
either multiple connections or multiplexing messages on a single connection.

b) low-latency application messaging
where a private machine just wants low-latency messages to an application
but can't accept incoming connections.
This may be useful for smaller devices - the public machine can do all the
security, high-level policy stuff and connection management, and the small
device can stay simple.

I do not want to 'tunnel' stuff through a firewall - I'm not into smuggling
information. Either you are the firewall admin & can open up the port, or
you are not the admin and you /shouldn't/ open up the port. The third
alternative is that the firewall admin doesn't care to let you listen - like
an ISP that restricts incoming requests. This situation would benefit from a
generic 'reverse http connector' - like an Apache mod (or hack) that did the
proper socket management.

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