Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx HTTP/2 server push support

hg.nginx.org

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Nginx HTTP/2 server push support

#51

Post by ghusbands »

linsomniac wrote: post #45

Just a heads up, we tried to enable H2 with haproxy 1.8.3 last week and had to roll it back because of a Firefox bug. I believe it's this one, which doesn't seem to be getting much attention: https://bugzilla.mozilla.org/show_bug.cgi?id=1427256

On that bug, it looks like the reporter has yet to give an update detailing what the bug actually is (the connection header is a mislead). Their update on Dec 30th says "I'm still working closely together with Willy from Haproxy to determine the actual root cause of http2 failures in Haproxy which only seems to affect Firefox". Without information on the actual fault, it seems like there's little the Firefox developers can do. It could easily be a Haproxy bug.

Re: Nginx HTTP/2 server push support

#52

Post by ko27 »

sebastiaand wrote: post #50
donatj wrote: post #35

Earlier quoted context omitted.

Ugh. That would work, but it’s such a hack. There should be a mechanism specifically for this. Is there’s no other good way?

There is an experimental RFC currently being discussed: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-di... The technique is derived from the H2O Casper work (and by the same author). I have a Javascript service worker implementation here: https://www.npmjs.com/package/cache-digest-immutable Note: This is still based on a Golomb-coded set (GCS). Current proposal under discussion is to use a Cuckoo filter.…

Do you have a source for that Cuckoo filter proposal?

Re: Nginx HTTP/2 server push support

#53

Post by Ajedi32 »

josephscott wrote: post #49
dalore wrote: post #43

Earlier quoted context omitted.

Good questions. I was looking at H2O and they solve this using what they call http-casper: https://h2o.examp1e.net/configure/http2_directives.html#http... > When enabled, H2O maintains a fingerprint of the web browser cache, and cancels server-push suggested by the handlers if the client is known to be in possession of the content. The fingerprint is stored in a cookie... That sounds interesting solution. Actually it…

That is the theory. The real world however can be very messy. More than two years ago Khan Academy measured how this would work for them - http://engineering.khanacademy.org/posts/js-packaging-http2.... - here was their summary: > The reality is not so rosy. Due to degraded compression performance, the size of the data download with individual source files ends up being higher than with packages, despite having achie…

> Due to degraded compression performance

Are there any efforts underway to fix that? Seems like you could solve that problem by sharing the compression dictionary between documents transmitted over the same connection.

Re: Nginx HTTP/2 server push support

#54

Post by SahAssar »

jbergstroem wrote: post #30

I've recently spent more time using H2O over nginx, mainly because of its more complete support of HTTP 2 (push, cache-aware push, ..) but also out of the box support for brotli compression and mruby (think lua landscape for nginx). Even though nginx made it easier to build and ship third party modules separately, I feel like the module community (as well as distro maintainers/packagers) haven't followed suit. There'…

The nginx brotli module is very easy to build, I usually build my openresty with brotli and nchan as add in modules and have never encountered any issues.

Re: Nginx HTTP/2 server push support

#55

Post by SahAssar »

Ajedi32 wrote: post #53
josephscott wrote: post #49

Earlier quoted context omitted.

That is the theory. The real world however can be very messy. More than two years ago Khan Academy measured how this would work for them - http://engineering.khanacademy.org/posts/js-packaging-http2.... - here was their summary: > The reality is not so rosy. Due to degraded compression performance, the size of the data download with individual source files ends up being higher than with packages, despite having achie…

> Due to degraded compression performance Are there any efforts underway to fix that? Seems like you could solve that problem by sharing the compression dictionary between documents transmitted over the same connection.

There are (SDCH), but they are basically abandoned and are close to being unshipped in chrome (which is the only browser that supported them): https://groups.google.com/a/chromium.org/forum/#!topic/blink...

I looked into using SDCH for topojson, since it seemed like a match made in heaven (a lot of repeated bytes in many files that are usually static), but since it never took off in usage it is being removed. The only major site that used it is linkedin.

EDIT: the continuation of this is basically what brotli is. Gather a dictionary of the most common byte-sequences on the internet, pre-ship that in every client and use that as the shared dictionary. But it will never be as good for specific use-cases.

Re: Nginx HTTP/2 server push support

#56

Post by SahAssar »

querulous wrote: post #40
bfred_it wrote: post #33

Earlier quoted context omitted.

I think, but could be completely wrong, that browsers can reject a pushed resource at the start. Since the "connection" cost for each resource is minimal, this wouldn't be too much of a problem. Someone confirm or deny this.

with http2 server push the server first sends a frame advertising it's going to push some resource (denoted by it's uri). the client can reject this resource before it's sent. this means the server has to delay sending to give the client the opportunity, however

The server does not delay sending until the advertising frame is acknowledged. So, for a large push the client might cancel the push, but for small pushes the client will already have received the data before the cancel can reach the server.

In general, if you are only pushing something that is both small and required that isn't a problem, but when using push for things like MPEG-DASH this becomes a point to think about.

Re: Nginx HTTP/2 server push support

#57

Post by SahAssar »

niftich wrote: post #47

As more software is adding support for HTTP/2 server push, I hope they'll start supporting a higher-level, implementation-agnostic, declarative way of specifying resources to push, which operates at a layer higher than server config directives. Google has a dead-simple JSON format [1] for this from 2015. [1] https://github.com/GoogleChromeLabs/http2-push-manifest

Most servers just read the preload headers from the backend and use that as a push. That won't work with "HTTP 103 Early Hints" (Since it needs to know what to push before the backend responds), but for now a preload header is a good compromise between ease-of-use and good-enough.

Re: Nginx HTTP/2 server push support

#58

Post by kolme »

linsomniac wrote: post #45

Just a heads up, we tried to enable H2 with haproxy 1.8.3 last week and had to roll it back because of a Firefox bug. I believe it's this one, which doesn't seem to be getting much attention: https://bugzilla.mozilla.org/show_bug.cgi?id=1427256

That's funny, we couldn't deploy H2 because there were problems with HAProxy/Apache and Safari. And it looks like a very similar issue:

http://www.wiktorzychla.com/2017/06/http2-keep-alive-and-saf...

Re: Nginx HTTP/2 server push support

#59

Post by ghusbands »

kolme wrote: post #58
linsomniac wrote: post #45

Just a heads up, we tried to enable H2 with haproxy 1.8.3 last week and had to roll it back because of a Firefox bug. I believe it's this one, which doesn't seem to be getting much attention: https://bugzilla.mozilla.org/show_bug.cgi?id=1427256

That's funny, we couldn't deploy H2 because there were problems with HAProxy/Apache and Safari. And it looks like a very similar issue: http://www.wiktorzychla.com/2017/06/http2-keep-alive-and-saf...

That bug is in HAProxy. The RFC clearly states that the presence of the Connection header makes the response malformed.

"An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed (Section 8.1.2.6)." and "Clients MUST NOT accept a malformed response. Note that these requirements are intended to protect against several types of common attacks against HTTP [...]"

(though Safari's response of repeatedly retrying as fast as possible is certainly problematic)

Re: Nginx HTTP/2 server push support

#60

Post by x25519 »

linsomniac wrote: post #45

Just a heads up, we tried to enable H2 with haproxy 1.8.3 last week and had to roll it back because of a Firefox bug. I believe it's this one, which doesn't seem to be getting much attention: https://bugzilla.mozilla.org/show_bug.cgi?id=1427256

That bug has been fixed in 1.8.3 (https://www.mail-archive.com/haproxy@formilux.org/msg28501.h...)

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1427256#c7

Post reply on HN