The State of HTTP in 2022
blog.cloudflare.com
blog.cloudflare.com
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.
GET -> FETCH
HEAD -> EXAMINE
POST -> SUBMIT
PUT -> REPLACE
DELETE -> REMOVE
CONNECT -> PROXY
OPTIONS -> ALTERNATIVES
TRACE -> ECHO
PATCH -> PARTIALUPDATE
Why ALTERNATIVES for OPTIONS?
SELECT CREATE UPDATE DELETE SUBMIT
and nothing more :D
#TheWebThatNeverWas https://youtu.be/8JOD1AQGqEg?t=1240
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
In practice, QUERY is most useful for where you want a bunch of different verbs for the same endpoint and need a body.
https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...
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.
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.
> 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.
That's not what your quote says.
Not having a defined semantics does not mean if is not supported. Just because some implementations fail to support GET with a request body that it does not mean all implementations should interpret it as a malformed request.
I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP.
Yes it does. "No defined semantics" = "out of spec".
> I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP.
You're out of the HTTP spec entirely.
Not defined means, it could be anything. If accepting body in GET is out of spec, then spec is supposed to say, GET cannot send body.
If there was an utter ban, then it would be against specification and not compliant, not merely out of specification.
That's not what it means at all. Being out of spec means the spec explicitly stating that a request with a body should be reject. If the spec does not state that a request with a body should be rejected then you are not required to reject a request which packs a body.
No, not defined means it's not within the purview of the spec. Spec doesn't care. You can send one. Maybe it'll work, maybe it won't, maybe it'll crash, maybe it'll be rejected, maybe some proxy along the way will strip it and the server won't even get it, maybe it'll get your client banned forever.
All of these are fine, because spec doesn't care.
> If accepting body in GET is out of spec, then spec is supposed to say, GET cannot send body.
No, then it would be against spec, like HEAD with a response 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
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.
A tradeoff would have been QUIC not requiring it but the higher level http/3 protocol requiring (if that’s possible idk)
BCP 78 "Pervasive Monitoring is an Attack" says the Internet should design new systems to resist such monitoring and so offering these intuitive properties for a new transport protocol made sense. And that's what QUIC is. In a BCP 78 universe it doesn't make sense to ship new protocols that will be rendered useless by the surveillance apparatus.
if you don't understand why these 3 things are on top of tcp, well, nevermind, I was going to say you shouldn't be designing networks buy you migth be already on the quic steering committee.
most committee now are a joke so that some googler middle mamaget makes it to jr director. sigh.
Handling certificate revocations (which would be needed to "ensure security"), does indeed imply the use of some way to check for the revocations in a timely manner. The revocation lists themselves can be tampered-with.
You're not answering my question (we both know why), and I never mentioned anything about WebPKI in any of my comments anyways.
TCP is a transport-layer protocol (ref the OSI model). The responsibilities of a transport-layer are neatly summarized here: https://en.wikipedia.org/wiki/Transport_layer
The OSI model is comprised of layers of abstractions, each building on-top of each other. Making TCP (a transport-layer protocol) depend on TLS (an application-layer protocol, ref https://en.wikipedia.org/wiki/Application_layer) is completely backwards, and makes absolutely no sense when considering the model.
The OSI model has been around for a very long while. If you have a degree in CS, or have studied networking in university - chances are you've had to learn about the OSI model. There's no reason to throw that away now, or reinvent the wheel.
Yet that's exactly how the internet works today.
Even imagining that for some reason I wasn't aware of that, why would it be relevant?
> If you have a degree in CS, or have studied networking in university - chances are you've had to learn about the OSI model.
And the waterfall software development model. A bunch of long obsolete data structures. Open Hypermedia (remember that? No? That's OK it doesn't matter any more).
What's happened here is that you've privileged a bad model that somebody probably taught you out of a textbook (hopefully while grimacing, since this is useless "information") over the real world experience of dozens of really smart people who work with actual networking and designed QUIC.
Maybe, if I'm giving you benefit of the doubt you've assumed "user" somehow means "undergraduate who is studying the OSI model" but it doesn't - billions of people use the Internet, far more than will study any degree, let alone Computer Science. And it's quite reasonable for them to expect their communications to have these three properties.
If your preferred model insists that we can't have security until the application layer then your model is wrong, just as surely as if you have a model of the Atom which assumes it's a solid ball of something (the plum pudding model, as with OSI perhaps some undergraduates were taught this model between when it was proposed and when experiments showed it's just wrong).
> "What's happened here is that you've privileged a bad model that somebody probably taught you out of a textbook"
So you're dismissing the OSI model as a "bad model" that "somebody taught me", yet there's this other shiny thing developed by "dozens of really smart people" and that's clearly the way to go because those people "work with actual networking".
> "And it's quite reasonable for them to expect their communications to have these three properties."
Their communications are clearly secured and tamper-proof already today, despite not using QUIC. How do you square that?
The security happens at the application layer, using mechanisms such as TLS. Additional security mechanisms can clearly come on-top. No need to bake everything into a single transport-layer protocol when there's endless flexibility available by layering the protocols on-top of each other.
> "If your preferred model insists that we can't have security until the application layer then your model is wrong"
How about instead of throwing fits about some vague ideas of "security" you actually provide concrete examples of what it is you're talking about, so that we can have a meaningful and constructive conversation about technology?
All I was saying is that there's no reason to introduce more complexity into the transport layer, since "security" is already handled by the application layer (on a per-application basis). It's unclear whether a single "security" model fits into the transport layer, which should be as agnostic and light-weight as possible (hence it's original intention - to facilitate the transfer of information between endpoints, and leave the rest to whatever consumes that information).
But there is, and I explained what that reason was. The real world is under no obligation to faithfully copy your OSI Model, on the contrary, the fact the OSI Model doesn't resemble the real world is a good reason to abandon it.
If your reason is "security" (whatever that means, you won't define that either), then I too, explained how that is guaranteed by application-layer protocols already today - so it's unclear why changing the transport layer is needed. Again, you're not saying anything concrete and keep handwaving - I don't think you really want to (or can) have a conversation, really.
When asked, our prof readily admitted that the OSI model was one of those design-by-committee experiments in purity that quickly broke down IRL.
So now what is the benefit of sticking to the OSI model, so that we can evaluate the pros and cons?
Lenovo Superfish exposed the limitations of the CA system.
It significantly reduces the attack surface (Certificate Authorities vs every ISP), it makes it a lot harder for state actors to pull off those attacks deniably with a gag order, and it makes it a lot easier for an informed but non-expert consumer to pick a secure-by-default solution.
The defense against compromised certificate authorities starts with platforms and browser makers. They demand that CAs implement certificate transparency logs to be included in root stores.
They also monitor CT logs, as do most large site operators. Facebook for example does not run an OS platform or browser, but has a robust CT monitoring program.
So if one of the random little CAs in the root store of your browser issues a rogue cert for “google.com”, it will be logged and seen, and that CA will risk getting kicked out of the root store. That’s what happened to Symantec, which was not a small CA.
In general it is safer and quieter for bad guys to target client devices with attacks like Pegasus, than systemic actors like entire CAs.
The victim might be the only one getting a collision as governments target them (and no security researchers get the compromised site + public key), and the Superfish fiasco shows that a collision is simply ignored by the browser.
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.
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.
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?)
Networking cost will be within callstacks for the system calls that send and receive packets (sendmsg, sendmmsg, recvmsg, recvmmsg).
Crypto cost in functions which sound like the crypto primitives being used. They typically won't have ssl_ in the name, because QUIC implementations directly make use of lower-level primitives - that are e.g. exposed by libcrypto/ring/etc.
Here's one example of an old profile using Quinn:
https://gist.githubusercontent.com/Matthias247/47dc290dde72e...
It clearly shows the networking and crypto parts (here using ChaCha20). However don't interpret too much into the actual values in this graph, since the profile is nearly 2 years, uses ChaCha20 instead of AES (much more expensive), and used loopback networking (cheaper than the real thing).
And keep in mind that "internal deployments" also include home servers and such, where it all makes even less sense.
[1] https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...
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.
Given this legacy, QUERY seems like an adequate solution. However, it seems to me like it's only intended for read queries. Write queries are generally not cacheable semantically, at least not in my world. Was the naming influenced by GraphQL by any chance, which distinguishes between queries (read) and mutations (write)?
That doesn't mean that the server can't change the resource itself for other unrelated reasons.
You can even use custom methods. I have a server that responds to the SALAMI method.
[0]: https://blog.cloudflare.com/building-privacy-into-internet-s...
Seems kinda pointless given that most of the internet is already behind a Cloudflare MITM anyway.
We're no less 10 years overdue for something like this.
And if it's not that... shame.
In reality through, now days it's a nightmare to implement a HTTP server/client (at least for individual developer like myself). HTTP/1 is already a struggle by itself, HTTP/2 is much worse with all the new concepts & HPACK etc it added, and then you have HTTP/3 which introduces an entire UDP transport for you to implement. There is no easy part in HTTP if you choose this route.
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.
I would raise hell with my ISP/cloud vendor/network operator if they thought that it was appropriate to cut corners and block me from using UDP. That’s more likely to DoS me if it means my games or video calls (or any of a million things that legitimately use UDP) stop working or become significantly degraded.
Feel free to question the direction the sun raises from.
> Denial-of-service is caused by applications that consume disproportionate resources based on untrusted user input. That’s entirely orthogonal to whether the application accepts input over UDP or TCP.
It's not, UDP-based protocols are generally mis-directionable and amplifying, which allows for much easier DOS-ing.
> I would raise hell with my ISP/cloud vendor/network operator if they thought that it was appropriate to cut corners and block me from using UDP.
They're doing the exact opposite of cutting corners. But hey good luck using video calls when the routers are melting, I'm sure that's going to be great.
> That’s more likely to DoS me if it means my games or video calls (or any of a million things that legitimately use UDP) stop working or become significantly degraded.
Only if you operate under the misguided assumption that hole-punching is not a thing.
Hell, any NAT requires specific handling of inbound connections to perform proper translation, and "drop" is a perfectly good default translation for an unrequested inbound.
If you're running a UDP service, you're going to need something more complex. maybe the host can drop all udp but port 80, but maybe the DDoSers can generate the reflection traffic to port 80 instead of random ports. If you're getting too much volumetric DDoS on your service port, you'll need to have some sort of filtering that understands your service traffic better and has enough ingress capacity. Usually that's expensive, not super flexible, and often adds a lot of latency.
Thanks, Cloudflare.
If you want to blame someone, blame the people who poisoned the well for everyone else.
How is this an "externality" of cloudflare's service? If anything, it is an "externality" of the server hosts.
But if we take a step back it's clear that Cloudflare is the entity here that can have the biggest impact. Spammers and customers are diffuse, Cloudflare isn't. How much of the blame they deserve, I don't really care, but theres a problem, they're in the best position to act, so they have a responsibility to. In my opinion, that's the best mindset for solving problems.
This is, to me, a bizarre notion. You're imposing some sort of moral edict upon cloudflare for providing an opt-in service to web hosts.
> they're in the best position to act
They have, and they decided that certain traffic requires additional consideration to distinguish from bad actors. Your refusal to cooperate is entirely on you.
Just because you don't like their solution doesn't mean that there is a better one. If you have better ideas, I'm sure they're all ears, as less intrusive is generally cheaper to implement.
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.
To tie this back to the topic at hand, you're complaining that a service has decided your traffic resembles known patterns from bad actors, and is asking you to go through an extra step to access the content.
Are there better options? Maybe, but it's utterly asinine to compare what cloudflare is doing to racial profiling.
How do you figure? You don't think far more DDoS events would occur if it was easier and more effective?
Not really. We are actually pretty good these days at stopping DDOS attacks.
In other cases, people try more sophisticated attacks (e.g. posting random terms to a search page to avoid caching) and that’s more of a problem but it’s probably like 1% of the total traffic because it’s moved out of script kiddie territory into something where you need to have more skills and people don’t generally do that without a way to make money from it. One challenge with a DDoS in that regard is that it’s not subtle so your ability to wage an attack goes away relatively quickly without constant work replacing systems which are taken offline by a remote ISP.
This is like saying no lock will stop a thief. Cost and difficulty matter, and requiring a full browser increases the challenge for an attacker enough that some people will give up and others won’t be able to send as much traffic. That’s not perfect but speaking from experience a surprising fraction of people will give up after a naive attack fails.
> 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…
I'm still having a hard time seeing how this doesn't eventually lead to a completely locked-down internet, where users can only use approved browsers and devices.
They have a list of steps for how a request would be made, where steps 2 and 3 are:
> 2. Safari supports PATs, so it will make an API call to Apple’s Attester, asking them to attest.
> 3. The Apple attester will check various device components, confirm they are valid, and then make an API call to the Cloudflare Issuer (since Cloudflare acting as an Origin chooses to use the Cloudflare Issuer).
In a theoretical future world where 99% of site operators have set this up for protection, and 99% of users are using approved browsers, how would one do something like...
Create a competitor to Google? You'd need to crawl the web for that. Would you imagine Apple or Cloudflare would gladly let your device request millions of tokens per hour? Or would that be throttled or disallowed entirely?
Use curl (or telnet, or [any other HTTP client]) to grab a page?
Use yt-dlp to download a YouTube video?
Scrape a bunch of data for an AI project? See this article from the front page where someone scraped a bunch of car listings from KBB and trained a model to estimate car prices and found some interesting results. https://blog.aqnichol.com/2022/12/31/large-scale-vehicle-cla... - would something like that be permitted under a system like this? Or might you need to own/rent an army of authorized devices with authorized browsers to do that experiment?
Here's the "you will be under our control" part of their scheme. Running any "unauthorised" software? Rooted/jailbroken? Certain "security" features disabled? Using third-party replacement parts? ... Social credit score too low? Too bad, you're now denied access.
For requests which are "reading" you just serve content, unless for some reason you only want human eyeballs to see your content.
In your proposed scenario, reading the publicly accessible contents of the web, there should be no problems. (Of course some percentage of sites will accidentally have required PAT at any time and be unscannable, but presumably they figure that out and fix it.)
Now for the good side: I, reluctantly, implemented a geolocation filter to control anonymous content additions to that service I was alluding to. I felt bad about it, but I also felt bad having to filter out content spam every day. It turned out that all my strange content spam came from one country, so I banned 143 million people from anonymous content creation for my convenience.
With PAT I can remove the national ban and let any "probably human" in.
I was going to cite the LinkedIn case where, last I had heard, the courts had decided that scraping was legal...
Headline [0] from April:
> Court rules that data scraping is legal in LinkedIn appeal
> LinkedIn has lost its latest attempt to block companies from scraping information from its public pages, including member pages.
... but upon googling it, I found a more recent [1] ruling :/
> LinkedIn prevails in 6-year lawsuit against data scraper
> The U.S. District Court for the Northern District of California sided with LinkedIn in its six year lawsuit against a firm that scraped data ...
So that sure puts a nail into the argument I was going to make. But still, while I think your use case lines up with the spirit of this kind of system, I think the reality is that it also would be used by every single site with a signup wall to kill off the archive.ph's of the world.
0: https://www.zdnet.com/article/court-rules-that-data-scraping...
1: https://iapp.org/news/a/linkedin-prevails-in-six-year-lawsui...
yeah, very few follow the original recommendation of showing captcha for ips that already showed signs of being bots etc.
but the vast majority shows captchas for absolutely anything. I can't even book a dmv appointment today without answering a gratutious one.
same will surely happen with PAT, especially because it is so easy for the implementer to shove it everywhere. people are lazy and dumb.
A: they won't. and that's the plan. not to mention that now those are the only two players (microsoft a late third) that can both attest you and profile you locally on the device for advertising profiling.
This is implemented in a privacy preserving way.
You will need to elaborate on that.
It's bad for freedom. Very, very very bad.
Talking about the "privacy" of what has been made publicly available makes no sense.
So are laws in the real world about stealing.
>Talking about the "privacy" of what has been made publicly available makes no sense.
Yes, it does. Users often wish to be able to delete or make something that was once public private. For example someone could post a picture of themselves on twitter. A year later they are no longer comfortable with having pictures of themself online so they go and delete them. Despite the user deleting them malicious scrapers will not delete them and keep those images. Another example would be setting your real name to your twitter name. Later you aren't comfortable using your real name so you change it away. Scrapers may still have your real name despite you wanting it to be a secret.
People also wish to be be able to do a lot of other things, but that doesn't make it right.
What becomes public history must remain immutable. Otherwise you're just going to encourage a state in which those who have the power to will destroy and rewrite the past to their advantage, to control the narrative over the population. The trendy phrase "right to forget" is effectively a "right to rewrite history".
It's interesting that you automatically call those wanting to preserve what could possibly be very important history "malicious scrapers".
I am going off of twitter's view. If you store tweets locally you must listen for when they get deleted and then delete them on your end too. If a scraper is breaking twitter's rules I consider that malicious scraper.
https://developer.twitter.com/en/developer-terms/policy#3.Up...
>If you store Twitter Content offline, you must keep it up to date with the current state of that content on Twitter.
https://www.ietf.org/archive/id/draft-ietf-rats-tpm-based-ne...
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.
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.
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
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
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.
I voted up because that is indeed neat tho.
I decided to try numbering the programs I write instead of naming them. I often use a prefix that can provide a hint.^1 For example, the yy prefix indicates it was created with flex and the nc in nc0 indicates it is a "wrapper script" for nc. If the program is one I use frequently, then I have no trouble remembering its number. In the event I forget a program number, I have a small text file that lists each yy program along with a short description of less than 35 chars.
1. But not always. I have some scripts that I use daily that are just a number. I also have a series of scripts that begin with "[", where the script [000 outputs a descriptive list of the scripts, [001, [002, etc. I am constantly experimenting, looking for easier, more pleasing short strings to type.
Each source file for a yy program is just a single .l file with a 3-char filename like 025.l, so searching through source code can be as simple as
grep whatever dir/???.l
head -5 dir/???.l
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.
You can't do LetsEncrypt?
See: https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
> I trust my services and devices
That is exactly the point. You trust your local, possibly dumb aka unmanaged switch. It's a little piece of silicone with no funny business going on.
Now if you plug a trusted device A as well as an untrusted device B in, the untrusted device won't see any traffic meant for device A:
https://wiki.wireshark.org/CaptureSetup/Ethernet#switched-et...
Point being: as long as you trust all network devices from a trusted machine to another, on a switched Ethernet network, no other device will see any of that traffic at all, on a fundamental, low OSI level. It's not even about HTTP/S at that point yet. All this is untrue for WiFi, where you will want HTTPS indeed.
I'm not advocating against HTTPS at all. I use it as much as possible. But it might actually not be necessary, locally under the right circumstances.
>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.
Well, the standard doesn't, but the browser(s?) implantation(s) do?:
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
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.
For the last decade or so I've gotten about 1k hits per day on my self-signed HTTP+HTTPS site. Random people will click past the scare tactics of modern browsers re: self signed if the topic is already technical and the demographic understands browsers are stupid. But all these people would be unable to visit under HTTP/2 or HTTP/3 only.
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.
then connect to :8000
I don’t think this is a conspiracy by Big TLS. Rather I think people are mad ISPs are injecting ads into their websites.
At least one brilliant, talented person has died because of Kiwi Farms.