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

Re: [rest-discuss] EBI vs. REST

Expand Messages
  • Jeffrey Winter
    I came across I pretty good summary of the various options. http://www.clipcode.com/peer/http_async_notif.htm ... From: S. Mike Dierken
    Message 1 of 14 , Oct 2, 2002
    • 0 Attachment
      I came across I pretty good summary of the various options.

      http://www.clipcode.com/peer/http_async_notif.htm


      ----- Original Message -----
      From: "S. Mike Dierken" <mdierken@...>
      To: <rest-discuss@yahoogroups.com>
      Sent: Friday, September 27, 2002 3:23 PM
      Subject: Re: [rest-discuss] EBI vs. REST



      ----- 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).




      To unsubscribe from this group, send an email to:
      rest-discuss-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • S. Mike Dierken
      ... From: Jeffrey Winter ... Yes - this is a good survey of different approaches. I m not sure the never-ending response /requires/
      Message 2 of 14 , Oct 2, 2002
      • 0 Attachment
        ----- Original Message -----
        From: "Jeffrey Winter" <j.winter@...>


        > 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).

        http://groups.yahoo.com/group/rest-discuss/message/1980
        Nobody challenged whether Upgrade is all that is needed for 'client behind
        firewall' or CONNECT is required - does anybody really know?



        >
        > ----- 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
        Message 3 of 14 , Oct 2, 2002
        • 0 Attachment
          On Wed, Oct 02, 2002 at 09:36:39AM -0700, S. Mike Dierken wrote:
          > http://groups.yahoo.com/group/rest-discuss/message/1980
          > Nobody challenged whether Upgrade is all that is needed for 'client behind
          > firewall' or CONNECT is required - does anybody really know?

          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 say nothing
          of flipping client/server, just upgrading to a new protocol.

          MB
          --
          Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
          Ottawa, Ontario, CANADA. distobj@...
          http://www.markbaker.ca http://www.idokorro.com
        • Paul Prescod
          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
            Message 5 of 14 , Oct 2, 2002
            • 0 Attachment
              ----- Original Message -----
              From: "Paul Prescod" <paul@...>

              > 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?

                Yes. Like HTTPS or "Reverse HTTP".

                > c) new method (TURN or something)

                I don't think that there is a need for it.

                Paul Prescod
              • S. Mike Dierken
                ... From: Paul Prescod To: S. Mike Dierken Cc: Sent: Thursday, October 03, 2002
                Message 7 of 14 , Oct 3, 2002
                • 0 Attachment
                  ----- Original Message -----
                  From: "Paul Prescod" <paul@...>
                  To: "S. Mike Dierken" <mdierken@...>
                  Cc: <rest-discuss@yahoogroups.com>
                  Sent: Thursday, October 03, 2002 12:23 AM
                  Subject: Re: [rest-discuss] EBI vs. REST


                  > 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.