Owdy Posted January 29, 2020 Posted January 29, 2020 I have Debian server. Is there any reason to not upgrade to http2?
Makoto Posted January 29, 2020 Posted January 29, 2020 Unless you don't use https on your site, no. Literally no reason not to. Testing for http/3 is already underway even.
Tarun Posted January 29, 2020 Posted January 29, 2020 Using http2 on my website, and it works just fine. If you're using Firefox you can get an addon to test that it's enabled. https://addons.mozilla.org/en-CA/firefox/addon/http2-indicator
Makoto Posted January 30, 2020 Posted January 30, 2020 I believe the latest release of IPS supports server push by default. It will send the push headers to the client if they don't already have an active session cookie.
Owdy Posted January 30, 2020 Author Posted January 30, 2020 28 minutes ago, Makoto said: I believe the latest release of IPS supports server push by default. It will send the push headers to the client if they don't already have an active session cookie. I dont need to install anything to server?
Makoto Posted January 30, 2020 Posted January 30, 2020 Your web server itself needs to support http2 and have it enabled, but outside of that no.
Owdy Posted January 30, 2020 Author Posted January 30, 2020 I have http2 now. This sayd i have http2, but not push https://http2.pro
Makoto Posted January 30, 2020 Posted January 30, 2020 Hmm, Are you using a CDN service such as Cloudflare by chance? IPS sets preload headers in the software itself, which is a form of pushing resources and can be interpreted by the web server and replaced with an actual http/2 push.This is no longer the case, see posts bellow. http/2 push and preloading is still kind of a new technology and historically it's not really been certain that using http/2 push is always better for reasons outlined here (if you're interested in the more technical aspects),https://dexecure.com/blog/http2-push-vs-http-preload/ Interaction with the HTTP Cache The server can also end up PUSHing resources which are already in the cache. In theory, browsers should be able to abort PUSH streams by sending a RST_STREAM frame to the server for resources which are already in their cache. But due to various browser bugs, this doesn’t work as expected yet. Even when these bugs do get fixed, the problem is not eliminated completely since the server can end up PUSHing a lot of frames before it recieves the RST_STREAM from the client. Cache digests is one proposal to solve this problem. Till browsers implement this, you can mimic their implementation via a service worker. However, this was back in 2017 when the technology was still new (and was when I was last actively following the technology), and I admittedly haven't been following the latest developments as much as I used to over the last year so I'm not sure how much things have improved since this was written (this may no longer be a problem at all, or may be significantly mitigated) I know there is still an issue with preloading fonts still (which IPS documents and is something I discovered myself trying to manually have fonts preloaded). This subject is probably something @bfarber or one of the developers actively working on this area will likely need to comment on.
Owdy Posted January 30, 2020 Author Posted January 30, 2020 Quote Hmm, Are you using a CDN service such as Cloudflare by chance? Nope, regular Debian server VPN
Makoto Posted January 30, 2020 Posted January 30, 2020 Are you able to provide a link to the site for testing by chance?
asigno Posted January 30, 2020 Posted January 30, 2020 If you're running Cloudflare you can also use HTTP/3
ASTRAPI Posted January 31, 2020 Posted January 31, 2020 To be able to benefit from http3 even if you enable it at Cloudflare level, your web server like Apache, Nginx etc should support it. Nginx will support it on the next software release in February. Keep in mind that the benefit from http3 will be more visible to big sites with high traffic and not for small sites... So it is good to add it in your server and use it but if your site doesn't have much traffic don't expect any magic performance improvement.
Makoto Posted January 31, 2020 Posted January 31, 2020 Your local web server does not need to support http/3 when using cloudflare to benefit from it. This is false information. You may marginally improve performance by supporting it at the server level as well, but not much. Also keep in mind http/3 is still in its very early stages of implementation and essentially none of your users will be able to utilize it at this point. It can only be forcefully enabled through a launch flag in Chrome Canary right now as an example. Lastly, the amount of traffic you have is completely irrelevant, you will still benefit from it just the same amount especially over a CDN like Cloudflare. http/3 is essentially HTTP Over Quic, and is a draft that has existed since the days of SPDY and before that. It's a major change to the web protocol that utilizes UDP based packets instead of TCP among other things. You can read into it more here if you're curious:https://en.wikipedia.org/wiki/QUIChttps://www.chromium.org/quic This thread is regarding http/2 push anyways.
Makoto Posted January 31, 2020 Posted January 31, 2020 Back on topic, I do see your web server supports http/2 @Owdy, but you do not seem to be delivering any preload headers to new connections. Can you confirm which version of IPS you are currently running?
Owdy Posted January 31, 2020 Author Posted January 31, 2020 31 minutes ago, Makoto said: Back on topic, I do see your web server supports http/2 @Owdy, but you do not seem to be delivering any preload headers to new connections. Can you confirm which version of IPS you are currently running? Latest.
ASTRAPI Posted January 31, 2020 Posted January 31, 2020 What’s the benefit of Server Push? When a browser requests a page, the server sends the HTML in the response, and then needs to wait for the browser to parse the HTML and issue requests for all of the embedded assets before it can start sending the JavaScript, images and CSS. Server Push potentially allows the server to avoid this round trip of delay by “pushing” the responses it thinks the client will need into its cache. However, Pushing responses is not “magical” – if used incorrectly, it can harm performance. Correct use of Server Push is an ongoing area of experimentation and research. HTTP/2 Server Push should do it conditionally so that it's browser cache aware and only does HTTP/2 Server Push on first vistors and lets browser cache serve subsequent visits. Sample code: add_header Link '<https://fonts.googleapis.com>; rel=preconnect; crossorigin; probability=1.0;'; add_header Link '<https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu4mxK.woff2>; as=font; crossorigin=anonymous; rel=preload;'; To read more in depth info on what HTTP/2 Server Push is and how it works, you'd want to read the guide at (a bit old but well explained): https://www.smashingmagazine.com/2017/04/guide-http2-server-push/ Nginx related sample code block: location / { http2_push_preload on; add_header Set-Cookie "pushcheck=pushed"; add_header Link $push_cookie; }
Makoto Posted January 31, 2020 Posted January 31, 2020 2 hours ago, Owdy said: Latest. Yeah, it doesn't seem like your server is PUSHing anything, nor is it sending preload headers. Need to get 288 kB of archives. :authority: hoitajat.net accept: */* accept-encoding: gzip, deflate user-agent: nghttp2/1.30.0 [ 0.766] recv SETTINGS frame <length=6, flags=0x00, stream_id=0> (niv=1) [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100] [ 0.766] recv WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=0> (window_size_increment=2147418112) [ 0.766] send SETTINGS frame <length=0, flags=0x01, stream_id=0> ; ACK (niv=0) [ 0.908] recv SETTINGS frame <length=0, flags=0x01, stream_id=0> ; ACK (niv=0) [ 1.038] recv (stream_id=13) :status: 200 [ 1.038] recv (stream_id=13) date: Fri, 31 Jan 2020 16:48:36 GMT [ 1.038] recv (stream_id=13) server: Apache [ 1.038] recv (stream_id=13) expires: Thu, 19 Nov 1981 08:52:00 GMT [ 1.038] recv (stream_id=13) cache-control: no-store, no-cache, must-revalidate [ 1.038] recv (stream_id=13) pragma: no-cache [ 1.038] recv (stream_id=13) x-ips-loggedin: 0 [ 1.038] recv (stream_id=13) content-encoding: gzip [ 1.038] recv (stream_id=13) vary: cookie,Accept-Encoding [ 1.038] recv (stream_id=13) x-xss-protection: 0 [ 1.038] recv (stream_id=13) x-frame-options: sameorigin [ 1.038] recv (stream_id=13) set-cookie: ips4_IPSSessionFront=lrukado3b087bkk0020j0pqkfm; path=/; secure; HttpOnly [ 1.038] recv (stream_id=13) set-cookie: ips4_guestTime=1580489316; path=/; secure; HttpOnly [ 1.038] recv (stream_id=13) set-cookie: ct_sfw_pass_key=bdaa84bc3d69c18a9824191e299a7918; path=/ [ 1.038] recv (stream_id=13) set-cookie: ct_cookies_test=%7B%22cookies_names%22%3A%5B%5D%2C%22check_value%22%3A%22d21961b3ba06bc7aeb3c5fcf636df94c%22%7D; path=/ [ 1.038] recv (stream_id=13) strict-transport-security: max-age=15768000 [ 1.038] recv (stream_id=13) content-length: 22076 [ 1.038] recv (stream_id=13) content-type: text/html;charset=UTF-8 [ 1.038] recv HEADERS frame <length=441, flags=0x04, stream_id=13> ; END_HEADERS (padlen=0) ; First response header [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.038] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.085] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.085] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.085] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=1291, flags=0x00, stream_id=13> [ 1.171] recv DATA frame <length=129, flags=0x01, stream_id=13> ; END_STREAM [ 1.171] send GOAWAY frame <length=8, flags=0x00, stream_id=0> (last_stream_id=0, error_code=NO_ERROR(0x00), opaque_data(0)=[])
Makoto Posted January 31, 2020 Posted January 31, 2020 Interesting. Actually, after investigating this further, it seems IPS will not send preload headers if you have guest page cache enabled, /* Do we want to preload anything? Only send preload headers for full page requests with a text/html response that have output. */ if( !$pageIsCached AND !\IPS\IN_DEV AND $output AND !\IPS\Request::i()->isAjax() AND $contentType == 'text/html' ) I assume IPS can't send preload headers for cached pages because it simply can't know for sure what resources need to be preloaded if a page is cached. I have guest caching disabled on my community, so I'm able to have the headers sent without issue. So, that's a tricky one. The only reliable way to enable this for everyone that I can see is to disable guest caching. For me personally, I can leave this disabled and see no noticeable performance hit, but this will vary significantly depending on your server environment and it's quite likely leaving guest caching on is better than disabling it just to gain access to HTTP push for guests. I only disabled guest caching on my server after benchmarking the performance under real world loads and monitoring the application speed with it on versus off, so I know in my situation it's worth doing that, but it may not be in yours. It's up to you if you want to experiment with doing this on your own server setup. In theory however, this should be working for logged in users. Though, considering logged in users already have browsed your site and have most things cached anyways.. it's a little moot. Though preloading could still be beneficial for other more dynamic resources (e.g. attachment images), I don't think IPS currently takes advantage of those potential benefits at the moment anyways. I can register for an account on your site in a bit if you want to confirm preloading is working for registered members, however. This is wrong. See:
Owdy Posted February 1, 2020 Author Posted February 1, 2020 I dont understand. Is something broken? Should i create ticket?
Makoto Posted February 1, 2020 Posted February 1, 2020 No, this is working as intended. You have http/2 enabled and that's working fine, you just don't have HTTP push enabled because IPS no longer supports programmatically sending the headers necessary for it. This is due to some technical limitations they will need to clarify when they have the time. But in general, I'd say don't worry about this. Upgrading to http/2 alone will net you a huge performance benefit, so this is still a very good step on your part. Don't worry about the more complex things unless you're just really into micro-optimization (like me).
Martin A. Posted February 1, 2020 Posted February 1, 2020 Are you sure about this, @Makato? To me it looks like the part that adds the HTTP header to push/preload the resources is commented out, and it has been since v4.4.1. There's also something a bit further down the removes this header is it's not the first visit. /* Send a link header for preloading */ //$httpHeaders['Link'] = implode( ', ', $urls ); /* We will only push resources (http/2) on the first visit, i.e. if the session cookie is not present yet */ Did a case-sensitive project search for "Link" to see if they push it somewhere else, but I can't find anything relevant.
Makoto Posted February 1, 2020 Posted February 1, 2020 Oh my, you are right @Martin A.. Thank you for pointing this out. In theory, this would be how it worked, but this is something that is commented out and no longer active. I'm not sure why it was disabled, this is again something we'll need the IPS team to comment on. I assume something wasn't working properly when they tested it at the time. (Preloading is still a relatively new thing so maybe it was disabled due to browser issues at the time.) Turns out the reason I see these headers on my community is because I have ngx_pagespeed configured to add these headers programmatically (and I completely forgot about that!)https://www.modpagespeed.com/doc/filter-hint-preload-subresources So, this is actually not supported natively by IPS (at least anymore). False correlation on my part, sorry!
Recommended Posts
Archived
This topic is now archived and is closed to further replies.