HTTP 103 Early Hints

Original link: https://blog.othree.net/log/2022/08/23/http-103-early-hints/

A few nights ago, my former colleague Tao Bai posted a Tweet saying that Chrome is going to remove HTTP/2 Server Push:

HTTP/2 PUSH is finally going away in Chrome 106: https://t.co/FFL8hmkRyf

HTTP 103 is the best way to early-hint out-of-band.

Thanks to the community and teams that made this possible (standards teams for 103, CDNs for implementing, Net team, huge effort)

— Patrick Meenan (@patmeenan) August 17, 2022

Taking a closer look, I found that everyone uses Server Push to improve the speed of the first screen of the web page, but Server Push has always had some intractable problems , such as not knowing whether there is a cache on the client side, which is more troublesome to implement and support, and Chrome Before removing Server Push, actually implement RFC-8279
HTTP 103: Early Hints
, in order to have an alternative to what Server Push is doing now.

Early Hint should be considered as proposed by Fastly. The author of the RFC document is Kazuho Oku . In fact, other Fastly people should also participate in the conception and experimentation. In the environment that supports Early Hints, an HTTP request looks like the following:

 Client request: GET / HTTP/1.1 Host: example.com Server response: HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script HTTP/1.1 200 OK Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script <!doctype html> [... rest of the response body is omitted from the example ...]

It is very special that there are two responses, the first is the status code of 103, then the content is Link headers, and then is the common 200 response. Seeing this, the first question naturally arises: the existing Are browsers compatible?

This question was also asked on Stack Overflow , and the answer is actually in the RFC file, but it was placed on the security side of Chapter 3. I didn’t find it because I skipped this chapter first. Anyway, about this The problem is that if it is HTTP/2, there is no problem. If it is HTTP/1.1, in theory, it should be compatible (no function but no error), but there is no guarantee that there are HTTP/1.1 clients in use. Correctly handle 1xx response, so it is recommended to return 103 only for HTTP/2.

After two days, I studied more carefully and found that the processing requirements of 1xx were defined as early as HTTP/1.1:

A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.

That is to say, the design as early as HTTP/1.1 allows 1xx to receive 200 responses, and should also support multiple 1xx responses, and the last 200 (actually 2xx to 5xx can be), it is called final response , As for the processing method, the 4.7 chapter of WHATWG’s fetch has a clear writing process. In the fifth sub-item in the ninth item of this chapter, the written code will probably grow into:

 while (true) { const response = await networkTransmit(); const status = response.statusCode; if (status >= 100 && status <= 199) { // handle 1xx response continue; } else { break; } } // handle final response

So in theory, Early Hints is designed to correctly support HTTP/1.1 but browsers that do not yet support Early Hints should be able to skip it normally, instead of treating it as a final response.

After solving the first problem, let’s take a closer look at the server response of the example just now:

 HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script HTTP/1.1 200 OK Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script <!doctype html> [... rest of the response body is omitted from the example ...]

I don’t know if there will be any doubts, why not just use the Link header responded in the 200 response? In fact, I thought so at the beginning, but this is entirely because this problem fell into my blind spot as a front-end engineer, because the mainstream of front-end development is SPA, usually the HTTP server returns a static HTML file, so I responded Super fast. However, if the HTML file of the response is dynamically generated by the programming language, you may need to query the database or the like, then the response time will be slower, and HTTP 103 Early Hints is used in this state. , Before your server-side program starts to process the request, it will first throw the status code of 103 and the content of Early Hints back to the browser, and then proceed to process data and generate HTML files. In this situation, Early Hints appears to be more useful. difference. Nitropack’s article explains it very clearly, and also attaches a detailed illustration.

Compared with Server Push, the design of Early Hints is actually much simpler. All transmissions are still based on the client side to see if there is a cache, and decide whether to send a request or not. This operation is very mature (compared to server push). I believe many places You can directly use the existing code to implement it. The biggest worry is that it is not compatible with HTTP/1.0, and then you will worry that the client side with HTTP/1.1 is not implemented correctly. After all, the processing mechanism of 1xx has been designed early. , but in fact 1xx has been widely used in recent years.

At present, Chrome supports Early Hints since 103, and it is expected to officially remove Server Push in 106. As for other browsers, it is not yet supported. Firefox has plans to support it, but the progress is a bit slow.

Finally, Fastly actually provides a website for testing: https://early-hints.fastlylabs.com/ , but this website is not used to test whether your browser supports Early Hints, but to test first 103 Will the response of 200 after the status have unexpected problems (that is, the compatibility test)? If you want to see the content of the back and forth directly, you can also use curl directly:

 curl -v https://early-hints.fastlylabs.com

This article is reproduced from: https://blog.othree.net/log/2022/08/23/http-103-early-hints/
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment