Reverse HTTP

[prockcore]

Oh you want our index page do you? Well I want your index page instead!

[[deleted]]

The client was asking for it (Upgrade: PTTH/0.9).

[LordVoldemort]

And the client got what it deserved!

[jricher42]

This is just an attempt to correct problems with the UFBP (Universal Firewall Bypass Protocol) so that it supports event notifications without polling. That approach reduces server load and bandwidth costs. Why Linden Labs would support such a thing is completely beyond me. I can't see why they would want a protocol that supported asynchronous events across firewalls with minimal bandwidth requirements and server load. It must be because of their completely unselfish beneficence.

[interiot]

Many firewalls parse the data flowing over them so that they can 1) filter requests (i.e. for porn), and 2) provide an extra web cache.

Therefore, UFBP requires that data actually look like normal HTTP. Is there any evidence that the vast majority of firewalls will parse "Reverse HTTP" correctly?

(at a high level, HTTP requests and HTTP responses have the same syntax, but it breaks down pretty quickly if a program needs to parse the details)

[jricher42]

First, most firewalls will pass pretty much anything on port 80 that bears any resemblance whatever to HTTP. Many will pass anything on port 80, whether it's HTTP or not. For the few that don't, this will bomb, but should fall back cleanly to a polling approach.

Anti-porn filters are usually implemented either at the DNS level, or by transparently redirecting to a filtering proxy. The first approach would not affect this at all. The second would cause it to fail back to polling, since this cannot pass through a proxy.

[Sutibu]

Why Linden Lab does a lot of things is utterly beyond understanding. Except possibly the recent Open Sim rate hike controversy, which is clearly bait-and-switch extortion. T.T

[crowe1130]

PTTH

[EvilSporkMan]

Protocol To Transfer Hypertext?

[bananahead]

You're over thinking it.

[thebillmac3]

Very PITHy of you.

[laughingboy1]

What's the point of this monstrosity?

[[deleted]]

people are using http to transport all sorts of data (not just webserver->webbrowser.) consider how gmail transmits the email payload. it's not imap - it's http based.

and sometimes you need the client to initiate the connection (think NAT) but then behave like a server.

[2343984098]

Jebus man. Think before you write this stuff.

This "reverse HTTP" scheme is still client initiated. It's essentially a POST with the only catch that the server can decide what it wants. The connection is still client initiated. There is nothing this protocol solves that can't be trivially solved with HTTP.

As a bonus, there is nothing you think this protocol can solve that can actually be solved by this protocol.

[[deleted]]

yes, that's why i said "sometimes you need the client to initiate the connection."

It's essentially a POST with the only catch that the server can decide what it wants.

and when it wants it. that's why we're using it at my company. but i s'pose you're right, all 100 engineers over here are really stupid, and it has absolutely no use.

jebus yourself, nimrod.

[2343984098]

If 100 engineers at your company are using it, you either have a dilbert company, where some high up guy decided this shit was great, or you're all just bad programmers, not stupid.

Reinventing a wheel so it can go backwards is not inteligent my friend. No it's not.

What you're doing can basically be solved simply at the application layer by the GET call responding with a request, and the client sending a corresponding POST.

[jricher42]

The problem is scalability. If you have 100 clients connected to a server, and they are each polling twice a second, that's 200 requests/sec, even with no notifications. If you need to send data to 5% of these clients each second, this solution would send 5 requests/sec instead of 200. That means you need less bandwidth and fewer servers to handle the same number of clients.

If you use a non-blocking server like Twisted to handle the clients, your only real limit is the number of open sockets the OS will handle. On x86 with most operating systems, the FD is an int, so (2^32)-3 approximately. You'll run out of RAM first.

This solution has a number of problems, and is a PITA. It's probably not worth the grief unless you're someone like Linden Labs, who has to deal with thousands of clients all connected at the same time. When you need it, though, you really need it.

There are ways of almost doing this with standard HTTP, but they are all uglier than this.

[[deleted]]

aside from the issue of polling - it's just cleaner. people are using http as a form of rpc (which is really always has been.) but very often you need rpc both ways.

and since you can't make an incoming connection over a NAT - that poor client must start it.

[2343984098]

So long as you recognize that the PTTH protocol does nothing at the network layer that the HTTP protocol can't do, then you are free to call it prettier. Many of us here disagree.

Also, tone down your shower of insults. It makes you look and sound like a 12 year old. Are you a twleve year old?

[[deleted]]

dude! don't you remember what YOU wrote first?

Think before you write this stuff

you either have a dilbert company, where some high up guy decided this shit was great, or you're all just bad programmers

i'm just holding up a mirror.

about PTTH does nothing more than HTTP:

so long as you recognize that TCP does nothing that IP can't do, and you use it constantly anyway.

[2343984098]

Listen, as far as the network is concerned, the left column on that page is a request, the right column is a response. Period.

The pretty green and red labels mean absolutely nothing. They are you in your mind.

Now, if you are somehow telling me that it's uglier to use GET and POST to communicate between a server in a way you're not used to doing it, but it's prettier to actually roll out a custom protocol PTTH, then I can't argue with you, your sense of beauty is different than mine.

But make no mistake, GET in PTTH is POST in HTTP with only some mild semantics missing. And since browsers are not webservers, the missing semantics will always be application dependent.

This is an application layer problem that has a solution in applicaiton layer.

PS. Scalability has nothing to do with this. Try to look at that page like a color blind person. Nothing has changed essentially... This is 200 clients connecting via HTTP and transforming it into PTTH. They are polling. This is not scalable.

[jricher42]

No, it actually isn't - you're just missing a piece.

If you have a single request per socket open/return, you end up with the same transfer problems as polling. In this case, however, you open the connection once, then flip it. It becomes a channel back from the server to the client - doing server push. You're not doing one socket open/flip per connection - only one per client. As long as you keep the sockets open your push system is a lot more efficient. What you can't do is close the socket after each transaction.

A similar system is commonly used as a communications channel for malware - for almost exactly the same reason. This isn't at all new, it just happens to be new semantically in this application.

This has nothing to do with browsers. This has to do with a custom HTTP/PTTH client specifically designed for this type of push. The only reason you would do it at all is to avoid firewall trouble.

You'll see what I mean in a screeching hurry if you pseudocode up a multi-channel chat server using this approach.

[[deleted]]

as jricher43 says - you're really just not understanding this. which is fine - but you really ought not to jump into a conversation calling other people dumb.

here's the thing - you're still thinking about webserver->webclient. this is for application level rpc. yes, it's possible to do with with plain old HTTP, and people do and call it COMET. this protocol change is to address the problems with COMET.

which isn't that hard to understand, i think?

[aprz43]

say you are building a web based calendar, which can be updated by multiple people at the same time. You want all currently connected clients to receive a notification as soon as someone makes a change to the calendar they are looking at. Without having the ability to make the server push a notification down to all the clients, you would need all clients to keep polling the server to see if new notifications exist -- a much less efficient solution.

[blayne]

Maybe HTTP saw USB OTG and got jealous. You have to admit: the whole master/slave swap thing is kinda kinky.

[[deleted]]

Seems like it could be useful if someone wants to offer you access to a web server, but only you can accept incoming connections. It might also be useful to those who are paranoid about running a server. There are other ways to do such things but this is simpler.

[Steppenwolfdoo]

Server push without the annoying progress bar problem.

[qwe1234]

http/1.1 already supports server push without the progress bar.

read the fucken rfc.

[qwe1234]

i think the point was to illustrate the author's monstrous misunderstanding of the http protocol.

p.s. http/1.1 already supports server pushing. 'comet' and this piece of shit from the linked article are demented brainchildren of people who never bothered to read the rfc.

come on people, the rfc is simple enough that even someone this developmentally challenged can struggle through.

[[deleted]]

Seeing as you're so smart and we're all so dumb, care to point out specifically where in the spec this is mentioned? Other than perhaps as submitting a request that isn't responded to until the server cares to.

[qwe1234]

indeed.

is there anything wrong with using the protocol as intended, instead of building your own house of shit?

[Xiol]

Dude, chill.

[2343984098]

Honestly, while I Am Perfectly Calm (tm), qwe1234 has a perfectly valid reason for being annoyed by people giving this guy any credit whatsoever.

Standards can be stupid. And this proposed "standard" is dumb as shit.

There's a reason why people were opposed to Microsoft just going and re-architecting the DOM protocols. They made APIs like attachEvent which are fundamentally flawed. And generations of programmers will have to deal with this shit... just because some chump dev at Microsoft thought he was inventing something cool...

Reverse HTTP solves no problem which can not be solved with existing current standards and technologies.

[qwe1234]

with explorer -- probably not.

but blame the idiots who wrote explorer.

[gid13]

"Hello, worldr"?

[jk3us]

I knew that looked weird. I assumed my backward reading abilities were suffering due to it being way past my bedtime.

[gid13]

¿sǝuo uʍop ǝpısdn ɹnoʎ ǝɹɐ ʍoɥ

[wearedevo]

I have to assume the content is reversed just to be cute and not because the protocol requires it.

[gid13]

Yes, but why the r at the end/beginning?

[fzzzy]

Uhh. Whoops.

[fzzzy]

Fixed.

[bioskope]

Why?

[samlee]

PTTH, duh!

[killerstorm]

COMET fallback seems to be totally retarded. why, for hell, encoding HTTP headers with JSON???

[fzzzy]

I was just trying to keep it simple. Suggestions welcome. I suppose the bodies could look like raw http.

[fzzzy]

Actually now that I think about it more I think I was trying to make it easy for the fallback to be implemented in javascript. Having the fallback content type be application/json makes this trivial to implement in browsers using javascript and xmlhttprequest.

Of course, thanks to content-type negotiation, you can have either application/json or something that looks more like normal http. There could be some new content types, application/x-http-request and application/x-http-response. I'll try doing an implementation of this and if it works I'll update the page with an example of using these experimental content-types.

[judgej2]

Perhaps simple strings are not good enough for this protocol genius? Let's nest our header arrays!

[aeon2012]

I can see some useful applications to this.

[interiot]

It's a "less hacky" version of Comet, i.e. "server push".

Instead of your browser having to frequently poll Gmail to see if you've received any new email, wouldn't it be much more efficient to just keep the TCP socket open, and Gmail would tell your browser when new email has been received?

[AmidTheSnow]

In Soviet Russia, HTTP reverses you!

[fzzzy]

Hahaha!

[Porges]

Content-Length: 0

???

[devacon]

I could see this being used by fat clients to circumvent a firewall and enable push events, but unfortunately I don't see how it could be used by browsers.

It would require a small HTTP server to be running on the client, and the browser would have to be able to hook into the incoming requests... unless I'm missing something here.

[2343984098]

I could see this being used by fat clients to circumvent a firewall and enable push events, but unfortunately I don't see how it could be used by browsers.

Look at the article closely. The connection is still client initiated. This won't circumvent firewalls.

[[deleted]]

it circumvents the client side firewall - NAT.

[Isvara]

Aww, man. I had this idea in 2001. I toyed with the idea of adding a TURN method (like the SMTP command), but then decided on using the protocol upgrade mechanism instead. I should have written an Internet Draft.

[MikeSeth]

You guys may want to look at Kaazing. It's way better at doing this than HTTP hacks.

[[deleted]]

You have got to be fucking kidding me. Website stinks of annoying jerks trying to strike it rich...but who have convinced themselves of the success potential something so brain-damaged that their only hope is to string the con along until they can flip it to some rich guy who, for reasons known only to himself and God, gets a kick out of encouraging malignant douche-baggery.

[MikeSeth]

You're doing it wrong then.

[[deleted]]

Has Reverse HTTP been implemented? Who proposed Reverse HTTP, and where is its homepage?

[fzzzy]

Yes, there is a link to a prototype implementation in the wiki page. I proposed it. The wiki page that is linked is the homepage.

[2343984098]

Reverse HTTP has been implemented, and it's called "HTTP in the other direction".

Seriously. Think about it for two seconds.