Hi! So I finally got to experiment a bit with HTTP2 push, preload link header, and 103 early hints and to compare them, especially in the context of API endpoints (similar to Vulcain [1]). My observations are:
Go does not yet support 103 Early hints (but PRs exist [2][3]). 103 Early hints seem to be very verbose if the main use case is to send preload link headers: "rel=preload;" could be maybe just implied? And if I want to specify "crossorigin=use-credentials" across multiple links, it becomes repetitive. Maybe it would be simpler to have 103 Preload with slightly modified syntax which would allow one to group preload links together based on attributes. Using a regular preload link header seems to be acted upon only after both HTTP headers and response body has been consumed by the browser. So it seems to me that the whole 103 Early hints is just because browsers do not process HTTP headers immediately when they receive them (if I force flush them before even sending the response body). Make me wonder if it would not be easier to standardize early processing of HTTP headers and early acting upon link headers in there instead of the whole 103 Early hints approach which requires new support across the full HTTP stack. Am I missing something here? Why do we even need 103 Early hints? HTTP2 push is even in 2022 sadly lacking high quality support across the stack and this makes it hard to use. Go does not support it in HTTP client library [4] and doing HTTP pushes seems to be slow [5]. Nor Chrome nor Firefox provide any insights into HTTP pushes in developer tools, so it is really hard to observe them and debug them (timings, headers, have they been canceled by the browser, informing a developer if HTTP push has not been used). With such bad support across the stack I do not wonder anymore why people have a hard time using HTTP pushes and using them effectively. So my conclusion is: given how hard it is to get HTTP pushes to be implemented across the stack, I worry that the same thing will happen with 103 Early hints. E.g.: will they be and how will they be exposed in developer tools? How will one be able to observe when they are in effect and when they are not? I wonder if in 5 years we will not be at the same point thinking about removing 103 Early hints. Maybe simply do early processing of HTTP headers and acting upon any link headers in there might be much simpler to both implement and expose in developer tools in browsers (almost no work needed there, only resources will be fetched earlier in timelines). And no need for any changes to the rest of the HTTP stack. [1] https://github.com/dunglas/vulcain [2] https://github.com/golang/go/pull/42597 [3] https://github.com/golang/net/pull/96 [4] https://github.com/golang/go/issues/18594 [5] https://github.com/golang/go/issues/51361 Mitar Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKLmikPu72BG56Jng13iu-JLQ5iw4v97D%3DvhmaP5-pF4JT_ydw%40mail.gmail.com.
