The REST Architectural Style List is a Public Group with 1951 members.

Primary Navigation

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

Expand Messages

Jeoff Wilks

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?

>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 manypeople who have already seen it, but my "Secure Protocol for Desktop Web
Servers" design uses this same strategy of having all push data be tiedto 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 isfixed before the push arrives, so that pushees ("sinks") can't betricked into pulling content they didn't want. A pushee can't even
receive a notice without prior arrangement. Overall, this system shouldbe no more susceptible to spam than pull-based systems.