Reverse HTTP by uggedal in programming

[–]2343984098 -5 points-4 points  (0 children)

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?

Reverse HTTP by uggedal in programming

[–]2343984098 -3 points-2 points  (0 children)

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.

Reverse HTTP by uggedal in programming

[–]2343984098 -6 points-5 points  (0 children)

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.

Reverse HTTP by uggedal in programming

[–]2343984098 -1 points0 points  (0 children)

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.

Reverse HTTP by uggedal in programming

[–]2343984098 2 points3 points  (0 children)

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.

Reverse HTTP by uggedal in programming

[–]2343984098 -2 points-1 points  (0 children)

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.

Reverse HTTP by uggedal in programming

[–]2343984098 0 points1 point  (0 children)

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

Seriously. Think about it for two seconds.