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

5286Re: [rest-discuss] REST requires HTTP or other transports

Expand Messages
  • Jeoff Wilks
    Oct 10, 2005
    • 0 Attachment

      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?


      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
    • Show all 14 messages in this topic