Talk:Reverse HTTP
What applications are there for this? I'm having trouble envisioning a problem that fits this solution. -- Strife Onizuka 13:26, 14 May 2008 (PDT)
- Strife, every problem containing symmetrical higher-level relationships between two parties could fit this solution.
- As one example of direct relevance to our current MMOX work at the IETF, consider two interoperating virtual world providers, who as peers are perfectly symmetrical in their relationship to each other at the VW level, but one of whom is isolated from incoming external access within a corporate protection domain. Reverse HTTP would allow totally symmetric application-level operation, despite the assymetry at the TCP level.
- The high-volume example is of course the desire for elegant communication between SL servers and SL viewers, given that the hosts upon which viewers are run only rarely are reachable and able to support incoming TCP connections. Morgaine Dinova 14:12, 8 March 2009 (UTC)
empty response body
Is there a reason 204 No Content isn't being used ? - SignpostMarv Martin 08:16, 14 July 2008 (PDT)
More reading
I think this idea has been abandoned - however some more details may be found in ptth (Reverse HTTP) implementation in a browser using Long Poll COMET by Donovan Preston. --oobscure 19:12, 12 January 2010 (UTC)
Retained for historic reasons
Donovan's blog still links to this page, and Google still indexes both, so there is one good reason for keeping it around. We don't want to contribute to URL rot 😂
That said, I'm not quite convinced of @Morgaine Dinova's argument for the 'extreme usefulness' of this 'symmetrical HTTP' protocol. I can imagine all sorts of problems when dealing with authentication and passing cookies both ways — too much can go wrong that way. Also, you'd need to set TLS up right at the start and just agree to keep the same symmetrical keys for the whole duration of the conversation, even when the roles get reversed after each request. Theoretically, there might be no problem at that point, but there would still be a difference between 'client' and 'server' right at the beginning — one of them, after all, would have to assume the client role and contact the server to do their TLS handshaking.
Of course, HTTPS was simply not an issue back in 2008 — so few people used it in the pre-Let's Encrypt era — so the question was moot back then. Authentication between 'well-known' servers would most likely rely simply on their respective IP addresses, using a simple whitelist on either side. Without a published RFC, it's hard to speculate how exactly this would work in today's context — or if it would make any serious difference. Opening two sockets for bidirectional communication on each side — one acting as client, the other as server — is, after all, not that expensive; I also understand that the PTTH
protocol would allow a certain degree of synchronisation, and capture the concept of a stateful HTTP connection (the stream would follow a very-well defined order which would not be irrelevant), but there are a trillion ways of turning a stateless communication, even both ways, into a stateful one.
From the perspective of looking back with the knowledge we have today, I really don't think this protocol would be useful at all, except, well, as a conceptual design for a peer-to-peer network on top of the otherwise very basic HTTP protocol, where the role of client and server would be vague and perfectly interchangeable. But we have so many peer-to-peer network protocols these days, all of which are much more adequate for such purposes as blurring the distinction of what 'client' or 'server' mean.
— Gwyneth Llewelyn (talk) 12:58, 31 January 2025 (PST)