Live data from Hacker News

Building Protocols with HTTP

tools.ietf.org

21–30 of 55 posts

Re: Building Protocols with HTTP

#21
post #11

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything over IP" was slowly being phase out for "HTTP over everything, everything over HTTP". The thing to realize here is how much middleboxes sit between a client and a server, boxes which are aware of higher layers than just IP. It's impossible today to deploy an Int…

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-inv…

You only need TLS for that. HTTP adds nothing security-wise.

Re: Building Protocols with HTTP

#22
post #20

Earlier quoted context omitted.

SSL/TLS with other protocols have a lot of usage too. SFTP/FTPS, SSH, SMTPS, etc.

SSH is a cryptographic network protocol that doesn't use SSL/TLS.

My bad. I should have said SSL/TLS/SSH.

* SFTP/FTPS (SSH)

* SSH (SSH)

* SMTPS (SSL, TLS)

Re: Building Protocols with HTTP

#23

Earlier quoted context omitted.

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-inv…

SSL/TLS with other protocols have a lot of usage too. SFTP/FTPS, SSH, SMTPS, etc.

FTPS is FTP over TLS. However SSH and SFTP has nothing to do with TLS.

Re: Building Protocols with HTTP

#25
post #5

Earlier quoted context omitted.

I agree. What is wrong with creating new protocols?

Anything outside of port 80/443 will be blocked at some point.

Blocked by who? Are you talking within some specific context, eg. corporate networks? Because HTTP/HTTPS are both TCP based protocols with some very limiting characteristics for many applications.

There are a whole lot of applications out there in widespread use that depend on UDP at the very least, eg. most multiplayer network games, just to use the simplest and most common example I can think of. Not everything can (or should) be stuffed into a HTTP transaction.

Re: Building Protocols with HTTP

#27
post #15

> Applications that use HTTP are encouraged to allow an arbitrary URL to be used as that entry point. For example, rather than specifying "the initial document is at "/foo/v1", they should allow a deployment to use any URL as the entry point for the application. Is this really saying that, for example, I shouldn't have an API specification that says "to fetch a list of users", send a GET to `/api/v3/users`? What's th…

API servers may need to co-exist, by mounting them into a hierarchy. You can certainly have `/api/v3/users`, but you should have enough configurability to support mounting that under `/yourapp/api/v3/users` so that someone doesn't need to rewrite URLs in a proxy.

Re: Building Protocols with HTTP

#28
post #5

Earlier quoted context omitted.

Anything outside of port 80/443 will be blocked at some point.

Blocked by who? Are you talking within some specific context, eg. corporate networks? Because HTTP/HTTPS are both TCP based protocols with some very limiting characteristics for many applications. There are a whole lot of applications out there in widespread use that depend on UDP at the very least, eg. most multiplayer network games, just to use the simplest and most common example I can think of. Not everything can…

Yes, the blocking problem mostly affects corporate networks or shady wlan access points.

Game developers don't really have a problem with using UDP/TCP on random ports.

Re: Building Protocols with HTTP

#29
post #28

Earlier quoted context omitted.

Blocked by who? Are you talking within some specific context, eg. corporate networks? Because HTTP/HTTPS are both TCP based protocols with some very limiting characteristics for many applications. There are a whole lot of applications out there in widespread use that depend on UDP at the very least, eg. most multiplayer network games, just to use the simplest and most common example I can think of. Not everything can…

Yes, the blocking problem mostly affects corporate networks or shady wlan access points. Game developers don't really have a problem with using UDP/TCP on random ports.

Sure, but there's a bit of a stretch from there to the parent posters claim "anything outside of port 80/443 will be blocked at some point" as a justification not to develop new, non-HTTP based protocols.

Re: Building Protocols with HTTP

#30
It's the next logical step to me. We have the Link, Internet, and Transport layers pretty well sorted. The Application layer is the next in line and it seems likely the web is going to win. A good thing about the web winning(and possibly part of the reason it's winning)is it has a lot of the next(and possibly final) layer already standardized. I'm not sure what you'd call it, let's say the Semantic Layer, all our human shit. (HTML, XML, and all the data formats, etc).
Post reply on HN