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

REST requires HTTP or other transports

Expand Messages
  • scottgregory
    Hello; Most of the discussion around REST that I can find refers to HTTP as the only transport used. While I understand that REST is an Architectural Style,
    Message 1 of 14 , Oct 5, 2005
    • 0 Attachment
      Hello;

      Most of the discussion around REST that I can find refers to HTTP as
      the only transport used. While I understand that REST is an
      Architectural Style, and not a specific implementation, it maps well
      to the GET/PUT, etc. of the HTTP headers, and most people seem to
      leave it at that.

      Are the two inextricably tied? Have people built real applications
      using different, e.g. MQ or other MOM type async transports, than
      HTTP?

      Thanks
      sdg
    • Hugh Winkler
      ... [hvw] I m not quibbling when I remark that HTTP is an application protocol, not a transport . It s a protocol for apps that transfer hypertext messages
      Message 2 of 14 , Oct 5, 2005
      • 0 Attachment
        >
        > Most of the discussion around REST that I can find refers to HTTP as
        > the only transport used.

        [hvw] I'm not quibbling when I remark that HTTP is an application protocol,
        not a "transport". It's a protocol for apps that transfer hypertext messages
        around. TCP is a transport. The Soap/WS-* folks, too, finally recognize that
        distinction.

        > While I understand that REST is an
        > Architectural Style, and not a specific implementation, it maps well
        > to the GET/PUT, etc. of the HTTP headers, and most people seem to
        > leave it at that.
        >
        > Are the two inextricably tied? Have people built real applications
        > using different, e.g. MQ or other MOM type async transports, than
        > HTTP?
        >

        [hvw] Roy Fielding reverse-engineered the way the web worked and called that
        the REST style. You could design other RESTful systems using MOMs. You'd
        build in these characteristics

        o You'd pass around hypertext documents that maintain the application state.
        o These documents would be the representations of some resources you could
        identify by some identifier ( ideally, URI)
        o The message processor would have a pretty limited number of verbs (could
        have just "process this"). The verbs don't have to be limited to just the
        fab four, either.


        But yeah, web apps are the archetypal REST apps, so that's where most of the
        discussion lies.


        Hugh
      • Walden Mathews
        Hugh, ... There could be a lot of them, as long as they make sense when applied to *any* resource: example: GET /my/bank/account (good) example: LOCK
        Message 3 of 14 , Oct 5, 2005
        • 0 Attachment
          Hugh,

          : o The message processor would have a pretty limited number of verbs (could
          : have just "process this"). The verbs don't have to be limited to just the
          : fab four, either.

          There could be a lot of them, as long as they make sense when applied
          to *any* resource:

          example: GET /my/bank/account (good)
          example: LOCK /my/bank/account (good)
          example: GETSTOCKQUOTE /my/bank/account (bad)*

          It is a matter of consistency, not parsimony, although the latter is
          probably a desirable side-effect.

          Walden

          * until my bank account becomes publicly traded, anyway
        • Jon Hanna
          ... HTTP is not a transport protocol. Abusing HTTP to serve as a transport protocol is one of the things that can lead to people not taking advantage of the
          Message 4 of 14 , Oct 5, 2005
          • 0 Attachment
            scottgregory wrote:
            > Hello;
            >
            > Most of the discussion around REST that I can find refers to HTTP as
            > the only transport used.

            HTTP is not a transport protocol. Abusing HTTP to serve as a transport
            protocol is one of the things that can lead to people not taking
            advantage of the RESTful nature of HTTP.

            HTTP is not the only possible RESTful application protocol, indeed if we
            were starting from scratch we could probably do better. However it's
            development did go hand in hand with that of the REST style,
            particularly the changes that led to HTTP1.1 being developped as a
            successor to HTTP1.0.

            Hence when we are talking about REST we are most often talking about
            HTTP as the application protocol (with TCP/IP or perhaps a secure
            transport protocol built on top of TCP/IP as the transport protocol) but
            this is not necessarily the case.
          • Hugh Winkler
            ... [hvw] Excellent point. Further thoughts: One reason the web has been successful is that REST enabled all kinds of apps to run using this simple protocol.
            Message 5 of 14 , Oct 5, 2005
            • 0 Attachment
              >
              > There could be a lot of them, as long as they make sense when applied
              > to *any* resource:
              >
              [hvw] Excellent point.

              Further thoughts: One reason the web has been successful is that REST
              enabled all kinds of apps to run using this simple protocol. However HTTP
              has one thing MOMs don't have, and that is a standardized wire protocol. If
              you don't have a widely adopted wire protocol, then you won't interoperate
              with many others, and the value of designing using REST constraints is
              lower.

              XMPP + queues could change that.

              You could say that SOAP/WS got the wire protocol standardized, but omitted
              the application constraints. REST over MOM gets the application constraints,
              but has the wire protocol interop problem.

              REST constraints over XMPP/queues/pubsub? Wonder if that would take off...


              Hugh
            • Jeoff Wilks
              You might say that message-oriented middleware (MOM) follows the REST architectural style. * resource identifier = topic/queue name + message ID vs. URI *
              Message 6 of 14 , Oct 6, 2005
              • 0 Attachment
                You might say that message-oriented middleware (MOM) follows the REST architectural style.

                 * resource identifier = topic/queue name + message ID vs. URI
                 * representation = messages vs. documents
                 * verbs = SEND, RECEIVE, ACKNOWLEDGE vs. GET, POST, PUT, DELETE

                The course-grained style makes it relatively easy to patch systems together on a single message bus. The primary deficiency, as Hugh mentioned, is the lack of a standardized wire protocol, which prevents internet-scale messaging.


                On 10/5/05, Hugh Winkler <hughw@...> wrote:

                >
                > Most of the discussion around REST that I can find refers to HTTP as
                > the only transport used.

                [hvw] I'm not quibbling when I remark that HTTP is an application protocol,
                not a "transport". It's a protocol for apps that transfer hypertext messages
                around. TCP is a transport. The Soap/WS-* folks, too, finally recognize that
                distinction.

                > While I understand that REST is an
                > Architectural Style, and not a specific implementation, it maps well
                > to the GET/PUT, etc. of the HTTP headers, and most people seem to
                > leave it at that.
                >
                > Are the two inextricably tied?  Have people built real applications
                > using different, e.g. MQ or other MOM type async transports, than
                > HTTP?
                >

                [hvw] Roy Fielding reverse-engineered the way the web worked and called that
                the REST style. You could design other RESTful systems using MOMs. You'd
                build in these characteristics

                o You'd pass around hypertext documents that maintain the application state.
                o These documents would be the representations of some resources you could
                identify by some identifier ( ideally, URI)
                o The message processor would have a pretty limited number of verbs (could
                have just "process this"). The verbs don't have to be limited to just the
                fab four, either.


                But yeah, web apps are the archetypal REST apps, so that's where most of the
                discussion lies.


                Hugh





                ------------------------ Yahoo! Groups Sponsor --------------------~-->
                Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
                http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/W6uqlB/TM
                --------------------------------------------------------------------~->


                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                    http://groups.yahoo.com/group/rest-discuss/

                <*> 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/






                --
                Jeoff Wilks
                (703) 683-2753
                (703) 964-7368 mobile
              • Josh Sled
                ... And hypermedia. And caching/cache-control. And pull vs. push. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                Message 7 of 14 , Oct 6, 2005
                • 0 Attachment
                  On Thu, 2005-10-06 at 08:53 -0400, Jeoff Wilks wrote:
                  > The course-grained style makes it relatively easy to patch systems
                  > together on a single message bus. The primary deficiency, as Hugh
                  > mentioned, is the lack of a standardized wire protocol, which prevents
                  > internet-scale messaging.

                  And hypermedia. And caching/cache-control. And pull vs. push.

                  ...jsled
                  --
                  http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                • Walden Mathews
                  And all notions of state management.... When I see GET [uri] . I know what the response represents, and I know that the operation did not change the state of
                  Message 8 of 14 , Oct 6, 2005
                  • 0 Attachment
                    And all notions of state management....

                    When I see "GET [uri]". I know what the response represents,
                    and I know that the operation did not change the state of the resource
                    at [uri]. In other words, I know something of application behavior.

                    When I see "SEND [queue_id, msg_id]", I know nothing of
                    application behavior. Did this SEND affect the outcome of some
                    future RECEIVE? The answer is not in the protocol.

                    A system in which all resources are messages is not in application
                    space.

                    The similarity is skin deep at best.

                    Walden

                    ----- Original Message -----
                    From: "Josh Sled" <jsled@...>
                    To: "Jeoff Wilks" <jeoffwilks@...>
                    Cc: "Rest List" <rest-discuss@yahoogroups.com>
                    Sent: Thursday, October 06, 2005 9:31 AM
                    Subject: Re: [rest-discuss] REST requires HTTP or other transports


                    : On Thu, 2005-10-06 at 08:53 -0400, Jeoff Wilks wrote:
                    : > The course-grained style makes it relatively easy to patch systems
                    : > together on a single message bus. The primary deficiency, as Hugh
                    : > mentioned, is the lack of a standardized wire protocol, which prevents
                    : > internet-scale messaging.
                    :
                    : And hypermedia. And caching/cache-control. And pull vs. push.
                    :
                    : ...jsled
                    : --
                    : http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                    :
                    :
                    :
                    :
                    : Yahoo! Groups Links
                    :
                    :
                    :
                    :
                    :
                    :
                    :
                    :
                    :
                    : __________ NOD32 1.1245 (20051006) Information __________
                    :
                    : This message was checked by NOD32 antivirus system.
                    : http://www.eset.com
                    :
                    :
                  • Jeoff Wilks
                    ... Message buses can support hypermedia representations, just as HTTP can support non-hypermedia. Most messaging systems do support caching: clients can
                    Message 9 of 14 , Oct 7, 2005
                    • 0 Attachment
                      Josh Sled wrote:
                      > And hypermedia.  And caching/cache-control.  And pull vs. push.

                      Message buses can support hypermedia representations, just as HTTP can support non-hypermedia.  Most messaging systems do support caching: clients can create subscriptions to topic/queues and be guaranteed that they'll receive the message later. Again, the primary flaw is the lack of a standardized wire protocol. Pull vs. push is a difference, but in my opinion not a bad one -- more on that below.

                      Walden Mathews wrote:
                      > When I see "SEND [queue_id, msg_id]", I know nothing of
                      > application behavior.  Did this SEND affect the outcome of some
                      > future RECEIVE?  The answer is not in the protocol.

                      SEND would be most equivalent to POST, not GET. The equivalent to GET would be RECEIVE (or perhaps SUBSCRIBE is a more descriptive verb).

                      The difference in verbs illustrates the push vs. pull difference. In fact, Fielding argues in his dissertation that push-vs-pull is the key difference. He also states that a push model can not scale to web levels, though I question this assertion.

                      "The interaction method of sending representations of resources to consuming components has some parallels with event-based integration (EBI) styles. The key difference is that EBI styles are push-based. The component containing the state (equivalent to an origin server in REST) issues an event whenever the state changes, whether or not any component is actually interested in or listening for such an event. In the REST style, consuming components usually pull representations. Although this is less efficient when viewed as a single client wishing to monitor a single resource, the scale of the Web makes an unregulated push model infeasible."
                       -5.4 (paragraph 4) - http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

                      For reference/archive data, a pull model definitely makes the most sense. Yet the pull model shows cracks when used for real-time delivery scenarios like RSS. It seems to me that you could take all the other benefits of REST (standardized wire protocol, URIs, distributed caching, limited verb set) and apply it to a push model (perhaps over XMPP) and see the end of problems like this:

                        "...InfoWorld.com now sees a massive surge of RSS newsreader activity at the top of every hour, presumably because most people configure their newsreaders to wake up at that time to pull their feeds. If I didn't know how RSS worked, I would think we were being slammed by a bunch of zombies sitting on compromised home PCs."
                       - http://www.infoworld.com/article/04/07/16/29OPconnection_1.html

                      "This is the scaling problem that I've been talking about since we launched Bloglines a year ago. It's a serious concern. Centralized services like Bloglines avoid this problem because we only fetch a feed once regardless of how many subscribers we have to it. Desktop aggregators can't do that, of course, and end up generating huge amounts of traffic to sites like Infoworld. There are various things that a desktop aggregator can do to mitigate the load, like using the HTTP last-modified header and supporting gzip compression. But the aggregator still has to query the server, so there will always be a load issue."
                       - http://www.wingedpig.com/archives/000162.html


                      On 10/6/05, Walden Mathews <waldenm@...> wrote:
                      And all notions of state management....

                      When I see "GET [uri]". I know what the response represents,
                      and I know that the operation did not change the state of the resource
                      at [uri].  In other words, I know something of application behavior.

                      When I see "SEND [queue_id, msg_id]", I know nothing of
                      application behavior.  Did this SEND affect the outcome of some
                      future RECEIVE?  The answer is not in the protocol.

                      A system in which all resources are messages is not in application
                      space.

                      The similarity is skin deep at best.

                      Walden

                      ----- Original Message -----
                      From: "Josh Sled" <jsled@...>
                      To: "Jeoff Wilks" < jeoffwilks@...>
                      Cc: "Rest List" <rest-discuss@yahoogroups.com>
                      Sent: Thursday, October 06, 2005 9:31 AM
                      Subject: Re: [rest-discuss] REST requires HTTP or other transports


                      : On Thu, 2005-10-06 at 08:53 -0400, Jeoff Wilks wrote:
                      : > The course-grained style makes it relatively easy to patch systems
                      : > together on a single message bus. The primary deficiency, as Hugh
                      : > mentioned, is the lack of a standardized wire protocol, which prevents
                      : > internet-scale messaging.
                      :
                      : And hypermedia.  And caching/cache-control.  And pull vs. push.
                      :
                      : ...jsled
                      : --
                      : http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                      :
                      :
                      : ------------------------ Yahoo! Groups Sponsor --------------------~-->
                      : Most low income households are not online. Help bridge the digital divide
                      today!
                      : http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/W6uqlB/TM
                      : --------------------------------------------------------------------~->
                      :
                      :
                      : Yahoo! Groups Links
                      :
                      : <*> To visit your group on the web, go to:
                      :     http://groups.yahoo.com/group/rest-discuss/
                      :
                      : <*> 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/
                      :
                      :
                      :
                      :
                      :
                      :
                      : __________ NOD32 1.1245 (20051006) Information __________
                      :
                      : This message was checked by NOD32 antivirus system.
                      : http://www.eset.com
                      :
                      :




                      --
                      Jeoff Wilks
                      (703) 683-2753
                      (703) 964-7368 mobile
                    • Roy T. Fielding
                      ... So would I if that was what I wrote, but it isn t. Dissertations are a successful walk through a minefield -- summarizing them is not. One of the
                      Message 10 of 14 , Oct 7, 2005
                      • 0 Attachment
                        On Oct 7, 2005, at 5:48 AM, Jeoff Wilks wrote:

                        > The difference in verbs illustrates the push vs. pull difference. In
                        > fact, Fielding argues in his dissertation that push-vs-pull is the key
                        > difference. He also states that a push model can not scale to web
                        > levels, though I question this assertion.

                        So would I if that was what I wrote, but it isn't. Dissertations
                        are a successful walk through a minefield -- summarizing them
                        is not. One of the professors who signed my dissertation,
                        David S. Rosenblum, was working at the time on Internet-scale
                        event-based notification systems.

                        <http://www.ics.uci.edu/~irus/wisen/index-old.html>

                        You might want to look at Rohit's dissertation for more exploration.
                        <http://www.ics.uci.edu/~rohit/>

                        > "The interaction method of sending representations of resources to
                        > consuming components has some parallels with event-based integration
                        > (EBI) styles. The key difference is that EBI styles are push-based.
                        > The component containing the state (equivalent to an origin server in
                        > REST) issues an event whenever the state changes, whether or not any
                        > component is actually interested in or listening for such an event. In
                        > the REST style, consuming components usually pull representations.
                        > Although this is less efficient when viewed as a single client wishing
                        > to monitor a single resource, the scale of the Web makes an
                        > unregulated push model infeasible."
                        >  -5.4 (paragraph 4) -
                        > http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

                        Unregulated push models are infeasible on the Web. There needs to
                        be something regulating the flow of events, which means aggregations
                        and source-based filtering. I did not even attempt to address that
                        topic because it wasn't *my* topic.

                        > For reference/archive data, a pull model definitely makes the most
                        > sense. Yet the pull model shows cracks when used for real-time
                        > delivery scenarios like RSS.

                        I think the key thing that people should learn from my dissertation
                        is that principled design means thinking about the problem you want
                        to solve first, within the context you need to solve it, and then
                        selectively applying constraints to get the properties you want.
                        REST was just one example of that method. A natural "next step"
                        would be to look at a different problem (say, ISENs) and see what
                        additional constraints could be added to EBI in order to make it
                        more scalable. I would not start with REST as the basis.

                        > It seems to me that you could take all the other benefits of REST
                        > (standardized wire protocol, URIs, distributed caching, limited verb
                        > set) and apply it to a push model (perhaps over XMPP) and see the end
                        > of problems like this:
                        >
                        >   "...InfoWorld.com now sees a massive surge of RSS newsreader
                        > activity at the top of every hour, presumably because most people
                        > configure their newsreaders to wake up at that time to pull their
                        > feeds. If I didn't know how RSS worked, I would think we were being
                        > slammed by a bunch of zombies sitting on compromised home PCs."
                        >  - http://www.infoworld.com/article/04/07/16/29OPconnection_1.html

                        Er, or they could just contract with Akamai and they would never
                        see any "massive surge". *shrug*

                        Push models suffer from a major social problem: those that gain the
                        most are the least likely to pay for it. For example, every news
                        service thinks that they are the center of the universe. Consider
                        what would happen if every blog client received an event whenever
                        a story was published that the news service *thinks* is worthy of
                        their immediate attention. We already know what happens: SPAM.
                        To solve the scalability problem you will first need to regulate
                        that social problem, because publishers will not self-regulate.

                        It is, however, one heck of a dissertation topic.

                        Cheers,

                        Roy T. Fielding <http://roy.gbiv.com/>
                        Chief Scientist, Day Software <http://www.day.com/>
                      • Jeoff Wilks
                        ... My mistake. Re-reading with emphasis on unregulated I now see exactly what you were saying. Looking at Rohit s
                        Message 11 of 14 , Oct 9, 2005
                        • 0 Attachment
                          On 10/7/05, Roy T. Fielding <fielding@...> wrote:
                          > > [...] the scale of the Web makes an unregulated push model infeasible."
                          > > -5.4 (paragraph 4) -
                          > > http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
                          >
                          > Unregulated push models are infeasible on the Web. [...]

                          My mistake. Re-reading with emphasis on "unregulated" I now see
                          exactly what you were saying.

                          Looking at Rohit's <http://www.ics.uci.edu/~rohit/> dissertation, he
                          presents a number of REST variations, culminating in what he calls
                          ARRESTED - Asynchronous Routed REST with Estimates and Decentralized
                          Decisions.

                          > Push models suffer from a major social problem: those that gain the
                          > most are the least likely to pay for it. For example, every news
                          > service thinks that they are the center of the universe. Consider
                          > what would happen if every blog client received an event whenever
                          > a story was published that the news service *thinks* is worthy of
                          > their immediate attention. We already know what happens: SPAM.
                          > To solve the scalability problem you will first need to regulate
                          > that social problem, because publishers will not self-regulate.

                          Agreed: spam is a serious side effect of push models.

                          If all SMTP messages had a universal resource identifier then perhaps
                          spam problems could be mitigated more effectively? For example,
                          imagine if SMTP messages were restricted so that they contain only the
                          equivalent of an HTTP "302 Found" response. The message itself is not
                          allowed to contain any content, only a Location header describing
                          where to GET the content. Because the GET requires the information
                          source to positively identify itself by means of a Location/URI, there
                          is some protection there. The value proposition for spammers goes
                          down: while they can still send messages, they can't deliver *content*
                          anonymously. A recipient that has never subscribed to that URI can
                          simply discard it without retrieving the content; or check the URI
                          against a spam registry prior to downloading content; etc.

                          The presence subscription approach used in instant messaging systems
                          also seems to be a fairly effective way of managing the social
                          problem. By forcing publishers to gain a presence subscription prior
                          to letting any of their messages through, you take away much of the
                          value of sending unsolicited messages. If SMTP required the use of
                          URIs to retrieve content, then email clients could also support
                          subscription-like capabilities.

                          > [...] I would not start with REST as the basis.

                          Yes, but this is REST-Discuss, where REST is at the center of the world. :)

                          --Jeoff Wilks
                        • Lucas Gonze
                          ... I have beat this hobbyhorse before, so have to apologize to the many people who have already seen it, but my Secure Protocol for Desktop Web Servers
                          Message 12 of 14 , Oct 10, 2005
                          • 0 Attachment
                            Jeoff Wilks wrote:

                            >Agreed: spam is a serious side effect of push models.
                            >
                            >If all SMTP messages had a universal resource identifier then perhaps
                            >spam problems could be mitigated more effectively? For example,
                            >imagine if SMTP messages were restricted so that they contain only the
                            >equivalent of an HTTP "302 Found" response. The message itself is not
                            >allowed to contain any content, only a Location header describing
                            >where to GET the content. Because the GET requires the information
                            >source to positively identify itself by means of a Location/URI, there
                            >is some protection there. The value proposition for spammers goes
                            >down: while they can still send messages, they can't deliver *content*
                            >anonymously. A recipient that has never subscribed to that URI can
                            >simply discard it without retrieving the content; or check the URI
                            >against a spam registry prior to downloading content; etc.
                            >
                            >
                            I have beat this hobbyhorse before, so have to apologize to the many
                            people who have already seen it, but my "Secure Protocol for Desktop Web
                            Servers" design uses this same strategy of having all push data be tied
                            to a subscription: http://www.gonze.com/http-notifications.html

                            Using that method, a push message is not allowed to contain any content,
                            but only a notice that content may be pulled. The location of a pull is
                            fixed before the push arrives, so that pushees ("sinks") can't be
                            tricked into pulling content they didn't want. A pushee can't even
                            receive a notice without prior arrangement. Overall, this system should
                            be no more susceptible to spam than pull-based systems.
                          • Jeoff Wilks
                            Lucas, Interesting paper, and one I had not seen before (as a relative newcomer to rest-discuss). One possible addition to your work: since many clients sit
                            Message 13 of 14 , Oct 10, 2005
                            • 0 Attachment
                              Lucas,

                              Interesting paper, and one I had not seen before (as a relative newcomer to rest-discuss).

                              One possible addition to your work: since many clients sit behind firewalls, it seems that HTTP proxying would need to be extended for notification purposes as well. For example, a firewalled sink is unable to receive notifications directly. As an alternative, it could maintain a connection with a proxy server, and receive its notifications via that server.

                              Perhaps you had envisioned leveraging a notification-enabled HTTP proxy <http://www.w3.org/TR/WD-proxy>, since you cited that in your Acknowledgements section?

                              regards,
                              Jeoff


                              On 10/10/05, Lucas Gonze <lgonze@...> wrote:
                              Jeoff Wilks wrote:

                              >Agreed: spam is a serious side effect of push models.
                              >
                              >If all SMTP messages had a universal resource identifier then perhaps
                              >spam problems could be mitigated more effectively? For example,
                              >imagine if SMTP messages were restricted so that they contain only the
                              >equivalent of an HTTP "302 Found" response. The message itself is not
                              >allowed to contain any content, only a Location header describing
                              >where to GET the content. Because the GET requires the information
                              >source to positively identify itself by means of a Location/URI, there
                              >is some protection there. The value proposition for spammers goes
                              >down: while they can still send messages, they can't deliver *content*
                              >anonymously. A recipient that has never subscribed to that URI can
                              >simply discard it without retrieving the content; or check the URI
                              >against a spam registry prior to downloading content; etc.
                              >
                              >
                              I have beat this hobbyhorse before, so have to apologize to the many
                              people who have already seen it, but my "Secure Protocol for Desktop Web
                              Servers" design uses this same strategy of having all push data be tied
                              to a subscription: http://www.gonze.com/http-notifications.html

                              Using that method, a push message is not allowed to contain any content,
                              but only a notice that content may be pulled.  The location of a pull is
                              fixed before the push arrives, so that pushees ("sinks") can't be
                              tricked into pulling content they didn't want.  A pushee can't even
                              receive a notice without prior arrangement.  Overall, this system should
                              be no more susceptible to spam than pull-based systems.





                              --
                              Jeoff Wilks
                              (703) 683-2753
                              (703) 964-7368 mobile
                            • Lucas Gonze
                              ... Agreed. Let s say there is a proxy sitting on the corporate firewall, and the proxy is able to initiate traffic within the firewall. Using my handshake,
                              Message 14 of 14 , Oct 10, 2005
                              • 0 Attachment
                                Jeoff Wilks wrote:

                                >Lucas,
                                >
                                >Interesting paper, and one I had not seen before (as a relative newcomer to
                                >rest-discuss).
                                >
                                >One possible addition to your work: since many clients sit behind firewalls,
                                >it seems that HTTP proxying would need to be extended for notification
                                >purposes as well. For example, a firewalled sink is unable to receive
                                >notifications directly. As an alternative, it could maintain a connection
                                >with a proxy server, and receive its notifications via that server.
                                >
                                >
                                Agreed.

                                Let's say there is a proxy sitting on the corporate firewall, and the
                                proxy is able to initiate traffic within the firewall. Using my
                                handshake, the client would send a callback URI which was hosted by the
                                proxy server, then arrange for a pickup from the proxy using the
                                standard method.

                                Such a proxy would indeed be a lot like http://www.w3.org/TR/WD-proxy.

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