The State of HTTP in 2022

https://blog.cloudflare.com/the-state-of-http-in-2022/

by harporoeder • 4 years ago

271 215 4 years ago

blog.cloudflare.com

The state of proliferating sites that won't let you access them because you're not using an "approved" browser with JS and cookies enabled, and hiding behind the "security" excuse to do so. Ironic that I can't even read an article about HTTP in 2022 because of that racket.

Thanks, Cloudflare.

zdragnar4• 4 years ago

It isn't your security they're concerned about, it is the server's- it is preventing DDoS attacks.

If you want to blame someone, blame the people who poisoned the well for everyone else.

maxbond2• 4 years ago

We can walk & chew gum here, spammers and DDoSers are poisoning the well for sure, but Cloudflare is responsible for externalities of their service.

userbinator8• 4 years ago

it is preventing DDoS attacks.

Is it? Those who want to DDoS will always find a way, and meanwhile users with slightly odd hardware/software are being locked out. Admittedly the latter is a minority, but one of the key tenets of the Internet and what made it so successful was interoperability. This is, in some ways, even worse than (but somewhat of a following effect of) the effective browser monopoly.

Calling it "security" when it's really about "availability" is another deceptive misdirection, because the former is something that can more easily persuade the sheeple.

I don't really like to go to extremes, but fingerprinting clients and deciding access based on such should really be regarded as a moral equivalent to racial profiling.

worldofmatthew• 4 years ago

DDOS attacks that exist because Cloudflare knowly protects booter websites which feeds the DDDOS economy with money to make DDOS botnets profitable?

mnot7• 4 years ago

The IETF is working on a solution to this, and Cloudlare is actively contributing and implementing; see https://blog.cloudflare.com/eliminating-captchas-on-iphones-...

dceddia3• 4 years ago

This plan looks even worse for privacy, and seems to rely on authenticating the unique device itself.

Know your user is coming from an authentic device and signed application, verified by the device vendor directly.

If they manage to get wide adoption of something like this it seems like a very bad day for privacy, and a joyous day for advertisers, anyone who wants to prevent web scraping, Google and/or anyone who might want to make it hard to crawl the entire web…

thataintright• 4 years ago

Why is the IETF letting the CIA influence the design of network protocols?

ddon• 4 years ago

May be this link will work for you?

https://archive.ph/1gcnQ

userbinator8• 4 years ago

Thanks for trying, but unfortunately archive.ph is also behind Cloudflare.

anenefan• 4 years ago

Funny enough I can actually view their article.

Despite that I can visit websites where admins that set permissions not overly tough, I still run into enough blocks due to cloudflare that I'm considering investing time (ok for the last few years I've been really really lazy, I'm happy enough to copy and paste so I can manually write a nasty comment ) so that for each "bad load" the web site can be added to my disallow list. It might only save the smallest amount of wasted bandwidth but I guess it all adds up.

1vuio0pswjnm74• 4 years ago

The "new" HTTP is clearly targeted at the "approved browser".

For example, this alleged "head-of-line blocking problem" that HTTP/2 purportedly "solves" was never a problem of HTTP outside of a specific program, the graphical web browser, the type of client that tries to pull resources from different domains for a single website. Not all programs that use HTTP need to do that.

For instance I have been using HTTP/1.1 pipelining outside the browser for fast, reliable information retrieval for close to 20 years. It has always been supported by HTTP servers and it works great with the simple clients I use. I still rely on HTTP/1.1 pipelining today, on a daily basis. Never had a problem.

There are uses for pipelining besides the ones envisioned by "tech" companies, web developers and their advertiser customers.

mnot7• 4 years ago

If early hints breaks your proxy, it’s likely your proxy doesn’t handle 1xx status codes correctly. Could you tell me which proxy it is (privately if you think it necessary)? I’d like to chase the bug with them.

raggi• 4 years ago

The big problem with pipelining in http 1.x is that a response can break the pipeline part way through and there is no way to know what the server processed. A response night for example, mid pipeline be connection:close and that’s that, did any subsequent request get processed? Who knows.

1vuio0pswjnm74• 4 years ago

HTTP/2 seems to be designed for (graphical, interactive) webpages.

The maintainer of a popular webserver has suggested HTTP/2 is slower than HTTP/1.1 for file download.

https://stackoverflow.com/questions/44019565/http-2-file-dow...

As I stated, I use HTTP/1.1 pipelining every day. I use it for a variety of information retrieval tasks, even retrieving bulk DNS data. To give an arbitrary example, sometimes I will download a website's sitemaps. This usually involves downloading a cascade of XML files. For example, there might be a main XML file called "index.xml". This file then lists hundreds more sitemap XML files, e.g., archive-2002-1.xml, archive-2002-2.xml, containing every content URL on the website beginning with some prior year all the way up to the present day. Using a real world example, index.xml contains 246 URLs. Using HTTP/1.1 pipelining I can retrieve all of them into a single file using a single TCP connection. Then I retrieve batches of the URLs contained in that file, again over a single TCP connection. Many websites allow thousands of HTTP requests HTTP/1.1-pipelined over a TCP single connection, but I usually keep the batch size at around 500-1000 max. Of course I want the responses in the same order as the requests.

The process looks something like this

    ftp -4o 1 https://[domainname]/sitemaps/index.xml
    yy030 < 1|(ka;nc0) > 2
    yy030 < 2|wc -l

    1337855

1337855 is the number of URLs for [domainname]. Content URLs, not Javascript, CSS or other garbage.

yy030 is a C program that filters URLs from standard input

ka is a shell alias that sets an environment variable that is read by the yy025 program to indicate an HTTP header, in this case the "Connection:" header set to "keep-alive" not "close" (ka- sets it back to close)

nc0 is a one line shell script

    yy025|nc -vv h1b 80|yy045

yy025 is a C program that accepts URLs, e.g., dozens to hundreds to thousands of URLs, on stdin and outputs customised HTTP

h1b is a HOSTS file entry containg the address of a localhost-bound forward TLS proxy

yy045 is a C program that removes chunked transfer encoding from standard input

To verify the download, I can look at the HTTP headers in file "2". I can also look at the log from the TLS proxy. I have it set configured to log all HTTP requests and responses.

Is this a job for HTTP/2. It does not seem like it.

This type of pipelining using only a single TCP connection is not possible using curl or libcurl. Nor is it possible using nghttp. Look around the web and one will see people opening up dozens, maybe hundreds of TCP connections and running jobs in parallel, trying to improve speed, and often getting banned. As with the comment from the Jetty maintainer, I suspect using HTTP/2 would actually be slower for this type of transfer. It is overkill.

IMHO, HTTP, i.e., in the general sense, is not just for requesting webpages and resources for webpages.

I find HTTP/1.1 to be very useful. It is certainly not just for requesting webpages full of JS, CSS, images and the like. That is only one way I might use it. Perhaps HTTP/2 is the better choice for webpages. TBH, if using a "modern" graphical browser, I would be inclined to let it use HTTP/2. Most of the time I am not using a graphical browser.

svnpenn• 4 years ago

Yep. Just try to cURL the page, and you get 403 Forbidden. That is completely unacceptable.

secondcoming• 4 years ago

HTTP is an unmitigated mess. It's in the same state as C++; tries to be everything but has lots of historical baggage that can't/won't be removed.

travisgriggs• 4 years ago

Similar thoughts. As I read through the “why HTTP took off” explanations, I was surprised that the more obvious “it was the first thing that a plurality of players networked on and after that it was all just bandwagoning, because it’s much easier to meet people at other people’s parties than try to host your own” wasn’t enumerated.

Simran-B5• 4 years ago

"Ease of use" is mentioned, and I suppose this refers to HTTP being text-based, pretty readable and intuitively understandable. HTTP/2 and later aren't like this anymore, for the sake of efficiency. It's a trade-off, but at this point I don't see much value in using it for APIs anymore. If you value efficiency and clean design, there are clearly better alternatives that aren't more complicated than what HTTP has become.

mhd• 4 years ago

Interesting, I'd say the legacy parts are the actual good things and most of the corporate giga-scale add-ons are what's bad about it, but then again, I'm sure that we get the same for C++, too…

einpoklum• 4 years ago

Well, if it were in the same state as C++, that means it manages to let you get things right despite the historical baggage by embracing newer features in the standard.

cryptonector• 4 years ago

HTTP will never go away. The reason it's so widely used is that browsers are universal -and universally available- clients for arbitrary applications. And on top of that, you can mash multiple sources of content. The latter is also the reason that the web's security model is so awful.

benbjohnson• 4 years ago

One implementation detail about QUIC that I was surprised by was that it requires TLS. That’s great for improving the security on the public Internet but it seems like it adds complexity and CPU overhead if you’re running on something like an internal Wireguard network. Overall, though, it’s a minor complaint. I did like how they split apart the QUIC and HTTP/3 protocol from one another.

mnot7• 4 years ago

The precedent for that was set by http/2; while the spec didn’t require it (Snowden happened after that decision was made), all of the inplementatuons did.

devmunchies• 4 years ago

I believe GP is talking about the lower level QUIC protocol. That’s like TCP requiring TLS.

A tradeoff would have been QUIC not requiring it but the higher level http/3 protocol requiring (if that’s possible idk)

danuker2• 4 years ago

HTTPS does not address state-level threats. Your browser trusts a load of entities by default, any of which could be forced to meddle with your data.

Lenovo Superfish exposed the limitations of the CA system.

IgorPartola• 4 years ago

I think it makes sense, I would just love to improve ergonomics around getting certificates for internal services.

For example, I use the TP-Link Omada Wi-Fi access points and have a local hardware controller for them. The hardware controller can have a static IPv4 (ugh for no IPv6 support) but since it doesn’t support Let’s Encrypt its only way to get a certificate is to upload one via the web GUI. I can of course create my own CA and install my own cert with a long expiration date but then that would mean installing my CA on a bunch of devices from which I might access the controller.

Maybe the solution is something like having your DHCP box also be able to run an ACME server scoped just to your local domain and have that CA be trusted for your local domain by all your devices that get their IP from the DHCPv4/6 via a DHCP option.

Matthias2472• 4 years ago

My experience as former technical lead of a major HTTP/3 deployment is that while TLS certainly adds CPU overhead, it's by far not as major as the overhead of TLS on top of TCP is.

QUIC in general is far less efficient than TCP+TLS. Very optimized implementations require about 2x CPU for bulk data transfers, more usual ones (and running on operating systems that don't support UDP segmentation offloads) require about 5x the CPU. From that CPU overhead, only a small part is crypto. Most CPU time is spent in the OS networking stack processing the tiny MTU sized packets. In an optimized implementation where crypto has a bigger impact, you might see around 30% CPU time being spent in crypto operations in a profile when using hardware-accelerated AES (chacha20 is worse). Which means one could gain that amount of CPU back for other things in a cryptoless QUIC. However in a less network-optimized deployment it would only be 10%.

What I however can understand is people not wanting to deal with the complexity of issuing, deploying and rotating certificates for internal deployments that are already secured by other means like wireguard. It could be a concern - but on the other hand tools like the k8s cert-manager already simplify the process for those environments. And of course one needs to consider whether QUIC is the perfect tool for those environments anyway - plain TCP has lots of strength too.

djbusby• 4 years ago

What kind of profiler can tell which areas the CPU is burning cycles?

Like, just mapping a bunch of known function and timing? Then every "ssl_" function is classified as crypto time? And every "net_" function is networking? (Or something like that?)

int_19h5• 4 years ago

My concern long-term is that browsers will simply drop other options.

And keep in mind that "internal deployments" also include home servers and such, where it all makes even less sense.

no_wizard• 4 years ago

I thought the most interesting bit was the privacy OHTTP which they’re building a service around[0]. How this will differ from a VPN will be interesting. The gist of it is that the http connections are naive and don’t really record an “accurate” up address or trace, if I understand correctly

[0] https://blog.cloudflare.com/building-privacy-into-internet-s...

intelVISA2• 4 years ago

Maybe I misunderstand but this just looks like a buzzword mix of proxy + QUIC (i.e. TLS wrapped HTTP).

Seems kinda pointless given that most of the internet is already behind a Cloudflare MITM anyway.

mnot7• 4 years ago

The idea is to compose intermediaries run by different parties, so that no single entity has access to both the unencrypted payload and client ip address / connection context. It’s a controlled form of proxying where the proxy doesn’t have access to the plaintext. Not currently designed for everyday browsing; the use cases are things like collecting telemetry.

comfypotato• 4 years ago

The link to the new query method [1] intrigued me. Could this, if widely adopted, make GraphQL obsolete? (Or am I admittedly ignorant as to exactly what they each do?)

[1] https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

kindaAnIdiot• 4 years ago

IIRC query is just a method that you'd use for your GraphQL route. It doesn't actually have any querying system defined in the spec (See final sentence here https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...)

mnot7• 4 years ago

If everything works out, grapnel could use it and queries would be cacheable by generic http caches. A lot would need to happen to make that work, though. The immediate motivation is to get an alternative to people who want to put a request body on GET.

mnot7• 4 years ago

Graphql. I love autocorrect.

Simran-B5• 4 years ago

The main focus of HTTP 2 and 3 was apparently performance, and hardly any of the other fundamental issues of the protocol. It's nice to see that some work is put into something like QUERY as well, which improves HTTP as an API protocol (REST) - although the motivation appears to be performance again and I always have mixed feelings when I see the term "idempotent" in a context that likely involves database systems. Too often, such requests do have side effects of some kind and preventing request retries throughout the stack isn't easy.

chucke• 4 years ago

Definitely not performance, QUERY is an improvement/hackfix. Browsers have a cap on size of the request headline path (used to be very small for IE7), and server software also tend to cap the size of it, as a security mitigation (smth like max header size, similar to what happens with cookies). For this reason, technologies such as elasticsearch or graphql, which allow for quite large query defs, use POST and fit the query in the body instead, which is not bound to the same limitations.

Semantically, such queries are cacheable, but the request being POST, intermediate edge proxies or CDNs won't cache the request. This means clients pay the penalty every single time. Moreover, browsers can't have url-based history with such solutions, as POST requests can't "go back".

So QUERY fixes this. Semantically. Now you have to build support in middle boxes for it, and browsers must support it as well.

rswail• 4 years ago

The "idempotency" is that the request should not cause a state transfer from the client to the server that causes the server to change the resource.

That doesn't mean that the server can't change the resource itself for other unrelated reasons.

Kamq• 4 years ago

HTTP methods don't really have functionality inherently attached. They're only semantically meaningful. Occasionally intermediate infrastructure will treat them slightly differently, such as a firewall stripping bodies from GET requests, but that's not part of the spec.

You can even use custom methods. I have a server that responds to the SALAMI method.

nesarkvechnep• 4 years ago

GraphQL is obsolete today as it was when it was released. You have HATEOAS and with it you can take advantage of HTTP caching. No, Redis is not the same.

cpsns• 4 years ago

Edit: Not worth commenting on this when I'm already getting accused of bad things. Sorry folks, but apparently wanting companies like CF regulated is too controversial.

aqeelat• 4 years ago

Can you elaborate?

bitwize2• 4 years ago

Kiwi Farms. This is about Kiwi Farms. Someone's a bit assmad that the internet increasingly filters hate.

shaggie762• 4 years ago

As someone who's had to deal with many DDoS attacks I'm rather horrified at the thought of QUIC: dropping UDP at the network border eliminates a lot of headaches.

userbinator8• 4 years ago

It's ironic to see that coming from a company which profits from DDoS prevention services.

shaggie762• 4 years ago

Sorry to mislead you; I don't work for a protection service but my company has had contracts with a handful of them and I've tested a handful more.

10000truths2• 4 years ago

I'm not sure I follow. Such attacks happen because of poorly designed protocols with very asymmetric resource requirements between endpoints. My understanding is that the QUIC handshake has measures in place to prevent it from being a vector for amplification/reflection based denial-of-service attacks.

masklinn4• 4 years ago

I'm not sure I follow.

They're saying that blocking UDP entirely is a very effective (and cheap) mitigation of DDOS.

Because QUIC is built on UDP, however, you can't just block it, you have to ingest it and dedicate resources to filtering between QUIC and other UDP traffic.

_eht• 4 years ago

My resolutions for 2023 include helping people not use Cloudflare.

CuteDepravity• 4 years ago

What's wrong with CloudFlare? I recently discovered their free zero trust http proxy and really love it

Gigachad• 4 years ago

They are a danger to the free and open internet.

superkuh5• 4 years ago

HTTP/1.1 support is the last bastion between the web and complete corporate control. Once the megacorp browsers and man in the middle companies like Cloudflare drop HTTP/1.1 we will no longer be able to host a website without the continued approval of a third party corporation. HTTP/2 and HTTP/3 implemenations require the use of CA based TLS.

Just to preempt misunderstanding: HTTPS is great. But HTTPS only, with no option for HTTP is very much worse than HTTP+HTTPS for human people. Despite being great for for profit companies and institutions.

MuffinFlavored• 4 years ago

HTTP/2 and HTTP/3 implemenations require the use of CA based TLS.

You can't do LetsEncrypt?

acdha3• 4 years ago

You can. You can also continue to use private CAs, which presumably could be used to add more options if something happens to Let’s Encrypt.

PenguinCoder4• 4 years ago

Not for LAN only personal websites.

csomar• 4 years ago

Let'sEncrypt is still a third-party entity.

superkuh5• 4 years ago

From my original comment,

Just to preempt misunderstanding: HTTPS is great. But HTTPS only, with no option for HTTP is very much worse than HTTP+HTTPS for human people. Despite being great for for profit companies and institutions.

Using LE is great. It's problematic that literally everyone uses it but it's better than it not existing. But using LE does not solve the problem of not being able to use plain HTTP.

e12e• 4 years ago

HTTP/2 and HTTP/3 implemenations require the use of CA based TLS.

Well, the standard doesn't, but the browser(s?) implantation(s) do?:

https://http2.github.io/faq/#does-http2-require-encryption

superkuh5• 4 years ago

Very few people are going to be setting the compile time options for the libraries that implement HTTP/3 to enable plain HTTP/3 (no one has for HTTP/2). So Google, MS, Apple, etc not supporting plain HTTP/3 is a defacto standard more powerful than the spec Google/MS openwashed through the IETF.

avx563• 4 years ago

Honestly I don't think browsers will drop HTTP/1 anytime soon because it's inconvenient/impossible to do HTTPS on a local network. I mean, Chrome shows Not Secure on http connections, but not on localhost, and it doesn't mean much anyway. Which is FINE. I mean, maybe input[type=password] gets an alert on HTTP? Just a thought.

exitheone3• 4 years ago

Nothing prevents you from using a self signed cert.

It adds security for local deployments as well because you either trust the local CA or your browser tells you that someone has owned your network

PenguinCoder4• 4 years ago

Nothing prevents you from using a self signed cert.

With the various web browsers continuing to disallow or blar warnings about "SELF SIGNED CERT", this is not true. There's a lot of _current issues_ trying to access a self signed HTTPS site using mainstream browsers because they know better than you do.

superkuh5• 4 years ago

I've been using self-signed certs on my websites for 20 years. Part of the problem is that the HTTP/3 implementations do not allow the use of self signed certs. CA based only.

est4• 4 years ago

But HTTPS only, with no option for HTTP is very much worse

Have to agree with this. Been playing with `window.addEventListener('devicemotion')` recently, that shit is https only, which means I can't debug it on a simple localhost. WTF.

diarrhea3• 4 years ago

Try a quick and dirty local reverse proxy like Caddy. It provides self-signed localhost TLS, trusted on the OS level (if you agree) such that the browser is none the wiser.

tgv• 4 years ago

$ python -m http.server

then connect to :8000

marvinblum• 4 years ago

https://github.com/FiloSottile/mkcert

astrange• 4 years ago

Tell your browser to stop putting up warnings about self-signed TLS then.

I don’t think this is a conspiracy by Big TLS. Rather I think people are mad ISPs are injecting ads into their websites.

opportune2• 4 years ago

HTTP/1.1 is never going away. Cloud vendors will need to support it approximately forever because so many applications are not HTTP/2 compliant, and technically not even HTTP/1.1 compliant (because of things like header casing) in a way that precludes “down casting” after ingress without a lot of hacky workarounds.

est31• 4 years ago

I'm still not over the fact that they made headers all-lowercase in HTTP/2. I know the reasons, but it's so weird to have all-lowercase headers. TBH I don't see much of an uptake in the community either: since HTTP/2 came out, I've barely seen lowercase headers be proliferated in documentation of headers, e.g. MDN lists them HTTP/1 style: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

avx563• 4 years ago

Someone should write a DevTools extension that uppercases the headers, if such a thing is possible. :)

codetrotter• 4 years ago

If you want to break protocol, I suggest that we also change all of the HTTP verbs for no reason whatsoever :^)

GET -> FETCH

HEAD -> EXAMINE

POST -> SUBMIT

PUT -> REPLACE

DELETE -> REMOVE

CONNECT -> PROXY

OPTIONS -> ALTERNATIVES

TRACE -> ECHO

PATCH -> PARTIALUPDATE

1vuio0pswjnm74• 4 years ago

If the Chromium/Chrome browser is open source then anyone should able to edit the source code to change the headers to whatever case they prefer and re-compile.

treve2• 4 years ago

Anything working with headers should always have been case insensitive, so there's no reason to update the any documentation.

opportune2• 4 years ago

As someone who works in infrastructure I disagree with this. While it’s true that applications should always have done this, many many do not and need to be dealt with. If they are third party paying customers, your only option is to figure out how to make things work, because asking customers to upgrade will piss many of them off.

The simple fact so many applications do not treat headers as case insensitive is one of the major things holding back http 2. With HTTP/1 it was suggested but not enforced. Upgrading to http/2 with forced-lowecasing breaks these applications

NickLamp2• 4 years ago

The new QUERY method strikes me as a really promising addition. Not being able to send a body with a GET-type request is a gnawing issue I have with HTTP

0xb0565e487• 4 years ago

Just send a POST request lol

HideousKojima• 4 years ago

But you're only "supposed" to use POST with requests that add/modify data, or something silly like that.

In practice, QUERY is most useful for where you want a bunch of different verbs for the same endpoint and need a body.

spiffytech• 4 years ago

QUERY is cacheable.

duxup• 4 years ago

In practice I think that’s exactly what many people do.

Existenceblinks2• 4 years ago

GraphQL is doomed?

NickLamp2• 4 years ago

I do... but there are good reasons to not want to. If you read the linked spec you can learn for yourself

https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

Waterluvian• 4 years ago

Is it that you can but you’re just told not to, even if both client and server agree on the semantics?

bruce511• 4 years ago

Interestingly though GET with data exists in the wild, and has for many years.

I manage a http library class, and a customer encountered an API that required a GET but with data. (think query parameters passed as XML).

I implemented that for the customer, and then implemented the reverse in the server class. I'm not going to say its used a lot, but it makes semantic sense.

Incidentally it also becomes true for DELETE which is another request typically without a body.

This is the first I've heard of QUERY though, so look forward to reading up on that.

sakisv• 4 years ago

Just a heads-up that cloudfront will return a 403 when it receives a GET with body.

It's documented and all but I still find it a peculiar choice. A 400 would have been better and less of a red herring.

asdfghjhgfderty5• 4 years ago

nothing on the spec prevents arbitrary data on body of a GET. but clients and proxies are implemented by lazy people who make excuses they are preserving some legacy security feature or something and continue to ignore the spec.

insanitybit2• 4 years ago

The spec is actually pretty clear on this - do not specify a body on a GET request.

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

Previously it was "SHOULD ignore the payload".

It's nothing to do with laziness or security - people are writing spec conforming software. And indeed every library I've used allows interacting with a body, even on a GET.

a_c• 4 years ago

Elastic search (used to?) use HTTP body as parameters for a GET request. IIRC the HTTP specification doesn't (again, used to?) mandate GET request to have no HTTP body

Edit: Example of Elastic search API with GET body, now deprecated https://www.elastic.co/guide/en/elasticsearch/reference/7.7/...

Edit 2: https://stackoverflow.com/questions/978061/http-get-with-req...

The now obsolete specification https://www.rfc-editor.org/rfc/rfc2616 , obsoleted by https://www.rfc-editor.org/rfc/rfc9110

jillesvangurp• 4 years ago

It still does. I don't think it violates the HTTP 1.1 specification but more that it is unspecified. It's just that a lot of http clients simply don't support doing HTTP GET with a body under the assumption that it is redundant / not needed / forbidden. Of course elasticsearch allows POST as an alternative.

People used to obsess a lot more about those HTTP verbs and their meaning a lot more than today. At least I don't seem to get dragged into debates on the virtues of PUT vs. POST, or using PATCH for a simple update API. If you use graphql, everything is a POST anyway. Much like SOAP back in the day. It's all just different ways to call stuff on servers. Remote procedure calls have a long history that predates all of the web.

Existenceblinks2• 4 years ago

I would love a queryable file format akin to sqlite but with simple spec tailor made for the QUERY method.

high_byte• 4 years ago

HTTP is such a mess. only a new protocol can save us, but at this point this is near impossible.

pdimitar• 4 years ago

What's this "HTTP core"? Please tell me it's just the sane parts of HTTP and without any dark corners and ambiguous specs? Please tell me it's something you can write a parser for in an hour?

We're no less 10 years overdue for something like this.

And if it's not that... shame.

jimjag• 4 years ago

IMO, the reason for the initial success of HTTP (1.x) was due to its extreme simplicity. Things like text-based protocol, straightforward stateless design, capability to implement both server and client in easy, basic code. All this meant that the protocol itself was stable, usable, and a reliable standard to use.

The current path is to drastically increase complexity due to the demands of the content provider overlord(s); Basically, in order to better accommodate the needs of Google (and a handful of others), we must redefine things for everyone. It's becoming a complex, over-designed protocol that is being crammed down people's throats, instead of a protocol that is embraced because it makes sense.

afiori• 4 years ago

HTTP 2 allowed for in-stream multiplexing

rubatuga• 4 years ago

It's interesting that cloudflare states on their own blog that HTTP/3 has no benefits in real-world usage:

https://blog.cloudflare.com/http-3-vs-http-2/

Alifatisk• 4 years ago

When can I expect, let’s say Rack & Rails to implement HTTP/3?

The State of HTTP in 2022

Related Stories