111–116 of 116 posts
Hi, I'm the author - please let me know if you have any questions!
In light of these vulnerabilities, should we disable Internet-facing use of HTTP/2 wherever we can?
However, if the only way you can use HTTP/2 is by having the front-end downgrade it to HTTP/1, I would recommend disabling it.
Earlier quoted context omitted.
I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of website…
Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup. https://en.wikipedia.org/wiki/HTTP_pipelining : says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support. https://forum.nginx.org/read.php?2,269248,269249#msg-269249 : Some person says that Ngin…
There are probably millions. IME, over 20 years of using pipelining, it is quite rare to find ones that don't. Here is a simple example.
Download the k-tree transcript archive from stackexchange.com
1116 HTTP requests, 1 TCP connection
26MB download
stunnel -fd 0 1.htm
cd;kill $(cat 1.pid)
cat > 1.l
int yy_get_next_buffer();
int fileno(FILE *);
int setenv (const char *, const char *, int);
int dprintf(int, const char *__restrict, ...);
#define httpMethod "GET"
#define httpVersion "1.1"
#define Host ""
#define jmp BEGIN
#define Y(x,y) fprintf(stdout,x,y)
int count,path,ka;
int httpheaders(){
setenv("httpMethod",httpMethod,0);Y("%s ",getenv("httpMethod"));
Y("%s HTTP/",getenv("Path"));
setenv("httpVersion",httpVersion,0);Y("%s\r\n",getenv("httpVersion"));
if(0==setenv("Host","",0))Y("Host: %s\r\n",getenv("Host"));
if(getenv("Connection"))Y("Connection: %s\r\n",getenv("Connection"));
fputs("\r\n",stdout);
return 0;}
%option nounput noinput
%s xa xb xc
xa "http://"|"https://"
xb [-A-Za-z0-9.:]*
xc [^#'| \r\n]*
%%
^{xa} count++;setenv("Scheme",yytext,0);jmp xa;
{xb} setenv("Host",yytext,1);if(!getenv("Host"))setenv("Host",Host,0);jmp xb;
\n path=0;setenv("Path","/",0);httpheaders();jmp 0;
{xc} path=1;setenv("Path",yytext,1);httpheaders();jmp 0;
.|\n
%%
int main(){yylex();exit(0);}
int yywrap(){if(count>1){
fputs("GET /robots.txt HTTP/1.1\r\n",stdout);
Y("Host: %s\r\n",getenv("Host"));
fputs("Connection: close\r\n",stdout);
fputs("\r\n",stdout);};
exit(0);}
^D
flex 1.l
cc -std=c89 -Wall -pedantic -static -pipe lex.yy.cEarlier quoted context omitted.
In light of these vulnerabilities, should we disable Internet-facing use of HTTP/2 wherever we can?
I think HTTP/2 is fine when it's used end to end. So if you've got a single webserver setup, or a reverse proxy that speaks HTTP/2 to the back-end, it's great. However, if the only way you can use HTTP/2 is by having the front-end downgrade it to HTTP/1, I would recommend disabling it.
I'd say that the main cause of these issues is the directive language used in the H2 spec almost only saying "this must be done like this" without giving rationale for the rules, meaning that implementations that were unable to implement them exactly the same way were left with no hint about what the trouble was nor how to address it. The new spec in progress and the extraction of the core semantics makes the whole thing a lot cleaner.
In addition, H2 uses much more resources per connection than H1, which encourages to coalesce them between the proxy and the server. But coalescing connections can easily cause some head-of-line blocking if coalesced front streams show different bandwidths. So even end-to-end H2 is not always a panacea.
Earlier quoted context omitted.
Out of the ecosystems I’m familiar with, Python application servers have terrible http2 support: neither gunicorn nor uwsgi supports it, and even new hotness like uvicorn is pretty far from it. I don’t think Ruby is doing much better? Correct me if I’m wrong.
But why would you need HTTP/2 perfect support in real world application server? They are never going to terminate the client traffic, they will speak with a load balancer which can speak HTTP/1.1 with them. Sure, if you are at webscale or even less you want everything on HTTP/2 for optimization sake. But in the rest of cases, even if you are in a solo project, you can easily enough put an nginx before it, or a cloud…
[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...
Earlier quoted context omitted.
I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of website…
Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup. https://en.wikipedia.org/wiki/HTTP_pipelining : says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support. https://forum.nginx.org/read.php?2,269248,269249#msg-269249 : Some person says that Ngin…
That's incorrect. This is pipelining as it is defined in RFC2616.
https://tools.ietf.org/html/rfc7230#section-6.3.2
It is not latency we are trying to save with HTTP/1.1 pipelining, it is server resources, namely the number of simultaneously open connections. (See Section 6.4)
RFC 2616 does not require parallel processing. It's optional.
Personally, I do not care about parallel processing. I want the responses returned in order. I get satisfactory performance from FIFO. That's because I only request resources from the domain I type into the computer.
A website that allows ads to be served from a variety of domains that the user never typed might have a problem with performance. However that is the web developer's problem, not the user's. Online ads are optional. There is nothing in RFC2616 that requires online advertising. The web works great without ads, and that is how I use it.
HTTP/2 is designed to serve the goals of companies that assist with online advertising. Google and others. Automatically triggering requests for ads from third party domains through webpages is a particular type of web usage, promoted by "tech" companies to support their online advertising "business model", but it is not the only type of web usage. It has performance problems. Go figure.
There is nothing to indicate any person outside of the "tech" industry is interested in this type of web use. How many users intentionally request ads. None. No user ever types in the domain of an ad server.
Requesting many small resources from the same domain, i.e., the domain the user types into the computer, using pipelined requests generally does not suffer from performance problems. It is fast and efficient for the types of web use that are not requesting ads from third party domains. Not to mention it is far more energy efficient.