
Building Protocols with HTTP - BerislavLopac
https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-06
======
heipei
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 Internet-wide layer-4 protocol other than TCP or UDP, and
increasingly it will be harder and harder to deploy a truly universal L7
protocol but HTTP. That's my limited view of this issue, how things like IPv6
might affect it I have no idea.

~~~
Immortalin
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-invent the whole public key dance on a
homebrewed setup.

~~~
paulddraper
SSL/TLS with other protocols have a lot of usage too.

SFTP/FTPS, SSH, SMTPS, etc.

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

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

* SFTP/FTPS (SSH)

* SSH (SSH)

* SMTPS (SSL, TLS)

~~~
tzahola
Still wrong. FTPS is vanilla FTP over TLS.

~~~
eganist
> Still wrong

You know that thing that gives security practitioners a bad reputation with
engineers?

You're doing it.

As opposed to this, why not something more like "it's not uncommon for these
two to be confused, but FTPS is FTP over TLS and isn't interchangeable with
SFTP"?

~~~
meeeh
Because it's longer? Pardon my foreign mind, but I do not understand, why you
are offended by a simple short and valid statement nor why you are
differentiating between "security pratitioners" and "engineers".

------
tptacek
There is some pretty dubious and I think wishful stuff in here, like
"applications should align their usage closely as possible with web browsers",
or the idea that ad-hoc protocols specified over HTTP should use links rather
than fixed URLs. Does anyone have the backstory on this I-D? Anybody can write
one, right?

~~~
totalthrowaway
He's not quite anyone.

[https://en.wikipedia.org/wiki/Mark_Nottingham](https://en.wikipedia.org/wiki/Mark_Nottingham)

Perhaps this is meant as a public service, just to gather best practices. If
you want to build your own thing, please go ahead, but don't call it HTTP.

~~~
tptacek
Fair enough, re Nottingham. Thanks for the link, that neatly answers my
question.

I strongly disagree that ignoring these suggested BCPs disqualifies an
application as "HTTP". As far as I'm concerned, if a typical middlebox will
reliably pass messages in it, it's HTTP.

------
Ajedi32
> 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
the alternative?

~~~
paulddraper
Hypermedia [1] As The Engine Of Application State (HATEOAS)
[https://en.wikipedia.org/wiki/HATEOAS](https://en.wikipedia.org/wiki/HATEOAS)

I not particularly a fan, but it's fairly common. It was popularized as one of
the pillars of the REST paradigm.

[1]
[https://en.wikipedia.org/wiki/Hypermedia](https://en.wikipedia.org/wiki/Hypermedia)

[2]
[https://en.wikipedia.org/wiki/HATEOAS](https://en.wikipedia.org/wiki/HATEOAS)

~~~
nickik
Is it actually common? Its talked about a lot, however in practice it is not
used much from what I can tell.

~~~
paulddraper
For starters, HATEOAS it's used as the foundation of the most common networked
applications in the world: web browsers.

Paypal uses it for their API.

But yeah, it's kind of like functional programming: the ideas are super common
and well understood. But by the numbers, the less pure imperative programming
paradigm is overwhelmingly more commonplace.

------
rixed
As I regard HTTP to be one of the main hindrance in todays IT industry I feel
it is my duty to add my voice to those trying to warn against the now decade
long trend to wrap everything into HTTP.

Things that HTTP makes more complicated:

1\. It's a verbose protocol with more often than not a really bad ratio
payload over metadata;

2\. Client authentication is hard;

3\. Server authentication is expensive;

4\. It's bad at streaming;

5\. It does not help a bit for RPC (no support for fan-out, quotas, fail-
overs, retries, ...).

Building an infrastructure on HTTP makes it so unreliable that I came to
consider one of the reason for Google technical superiority is that they early
ditched HTTP completely out and used stubby for everything instead. Maybe they
themselves view it as their secret sauce, which would explain why they've
never published a comparative review (that I'm aware of)? Many people I've
spoken to about this have expressed surprise that there is no HTTP flowing on
Google's veins. To many, removing HTTP is like removing the solid ground; but
to a former googler, loosing access to stubby and having to work with HTTP
again is a painful experience that requires quite some time to accept.

~~~
icebraining
So Google made gRPC (which uses HTTP) just to sabotage their competition? Man,
that's devious.

By the way, server (and client, if needed) auth is implemented by the TLS
layer. Do you propose using something else to secure other protocols?

~~~
rixed
They definitively pushed HTTP2 to help their clients move away from HTTP. My
guess is they cannot make stubby public without disclosing too much valuable
advantage and probably also knowing that this can only effectively run on
their own DC at that point. At least, gRPC is easy to unwrap from HTTP (which
is likely the very first step of processing on their side). Regarding
protobuf, I'm not a big fan but at least that's not JSON (another awful tech
that the industry is taking for granted).

Also: TLS is slow, and last time I asked for the best practice to do client
auth on HTTPS the general consensus seamed to be "don't do it".

------
ForHackernews
I really wish people would stop trying to cram everything into an HTTP-shaped
box.

~~~
sp4c3m0nk3y
I agree. What is wrong with creating new protocols?

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

~~~
nineteen999
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.

~~~
gsich
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.

~~~
nineteen999
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.

~~~
gsich
Of course, it's just a sloppy excuse.

------
PinkMilkshake
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).

------
bullen
Here is an example of how you can do this:
[https://github.com/tinspin/fuse](https://github.com/tinspin/fuse)

To use HTTPS, HTTP/2.0 or WebSockets is really not clever options when you can
do secure, simple and more performant stuff in clear text over HTTP/1.1

------
ori_b
"No".

