11 ms·

HTTP 103 – An HTTP Status Code for Indicating Hints

417 points by snomad 9y ago

badsectoracula 9y ago
This look nice to prefetch some stuff, although i have a feeling it'll break some not-so-nicely coded HTTP 1.1 clients that expect everything after the first CR/LF to be the content or -more likely- if the response isn't 200 for the request to fail :-P.
toast0 9y ago
This seems like it's only of interest if you need to do time consuming processing before deciding what http status code to send, because once you pick the status code, you can send it and start sending the rest of the headers. Is it common to serve something other than http 200 and to take a long time to do it -- but also be able to send something early sooner? Most of the the slow pages I've worked on were either slow to load all the details, but I knew it was 200 near instantly, and could get all the headers and the HTML head out pretty quickly, or had some structural problems that made them terribly slow, but we couldn't get anything out quickly anyway.
- xxs 9y ago
  The vast majority of the cases the status would be planned as 200... unless for whatever reason a timeout/error occurs during process. Then it may end up with error status and or redirect to an error handling page. Still very dubious proposal with minimal benefit(s).
tyingq 9y ago
Shouldn't it have a complimentary "denied" code? Or is 403 "Forbidden" the complement? Or maybe 401 "Unauthorized"? I guess it is related to preloading? Not quite getting the purpose. Edit: ahh, the complete story is here: https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-05 https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-0... (fixed). Note that someone fixed the capitalized "A" in "approved" in the title. It confused my initial reading of the article.
- matthewbauer 9y ago
  Yeah, the actual name is "103 Early Hints" not "103 Approved".
  - helb 9y ago
    I guess the title was meant as "… Approved as new status code", not "HTTP 103 Approved …". A bit unfortunate wording (and that capital A).
- alexbecker 9y ago
  As I understand it, the status code would improve performance in situations like the following: 1. Client requests X.html (which requires Y.css and Z.js) from Proxy. 2. Proxy forwards client's X.html request to Server. 3. [Server takes a long time to respond] 4. Server sends a 200 response to Proxy with X.html. 5. Proxy, per some configuration, adds Preload headers to this response indicating that Y.css and Z.js should be immediately loaded once this response is received, and sends it to Client. 6. Client requests Y.css and Z.js. With the 103 status code, this would look like: 1. Client requests X.html (which requires Y.css and Z.js) from Proxy. 2. Proxy forwards client's X.html request to server and, per some configuration, immediately sends a 103 response with Preload headers for Y.css and Z.js to Client. 3. [Server takes a long time to respond] 4. In parallel, Client requests Y.css and Z.js. 5. Server sends a 200 response to Proxy with X.html. 6. Proxy sends this response to Client. Note that since Y.css and Z.js are requested sooner, the final load time should be less.
  - stock_toaster 9y ago
    The proxy could also read preload headers from the Server, and start preemptively fetching Y.css and Z.js from the Server at the same time (step 2) it forwards the preload headers back to Client.
- itaris 9y ago
  Someone only read the headline.
richdougherty 9y ago
Summary: a new status code that lets the server send headers early, before the main headers. This helps with optimisations like preloading. Example from the document: HTTP/1.1 103 Early Hints Link: </main.css>; rel=preload; as=style 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: </main.css>; rel=preload; as=style Link: </newstyle.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script The client can start preloading the CSS and JavaScript before the main headers arrive. This is a nice optimisation. There are various security risks with sending multiple headers to non-conforming clients hence: "Therefore, a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly."
- tbodt 9y ago
  Sounds a lot like HTTP/2 push.
  - deleted 9y ago
    [deleted]
  - scott_karana 9y ago
    From the RFC intro: > HTTP/2 ([RFC7540]) server push can accelerate the delivery of resources, but only resources for which the server is authoritative. The other limitation of server push is that the response will be transmitted regardless of whether the client has the response cached. At the cost of spending one extra round-trip compared to server push in the worst case, delivering Link header fields in a timely fashion is more flexible and might consume less bandwidth.
    - mozumder 9y ago
      There are cache-aware HTTP2 server push technologies that can be used to cut that down wasted bandwidth. See: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http...
_justinfunk 9y ago
Title should probably be changed to have a lowercase "approved". It's a little misleading as-is.
- scott_karana 9y ago
  Agreed! I was confused when it was 103 Early Hints Not 103 Approved
edoceo 9y ago
Waiting for https://http.cat/103 https://http.cat/103 to be updated
Animats 9y ago
Can this be abused by middleboxes to stick in an interstitial ad before and during page load?
- dotancohen 9y ago
  Though other posters have pointed out why this is not the case, it _will_ make DDOS-by-linking much easier for "middleboxes" to orchestrate. I'm sure that there are further security issues to be found, as there are with all new technologies.
- DiabloD3 9y ago
  No, its pretty much only useful for hinting css and js files that will be loaded in the <head>.
  - rhizome 9y ago
    so...JS injection then?
    - traek 9y ago
      No. The JS would still be need to referenced by the page, this just affects preloading of assets.
      - rhizome 9y ago
        So a far-side check, but does it not execute it until everything checks out? Y'know, now that I think about it more.
        vertex-four 9y ago
        It literally just says "please download this into the browser cache". Nothing happens to things in the browser cache - they certainly don't get executed. Later, if a page tries to load resources, it might come from the browser cache.
acdha 9y ago
Has anyone looked into implementing this with Varnish? It seems like a great way to handle non-streaming backend servers.
fiatjaf 9y ago
Isn't this way too complicated to define and implement considering that HTTP/2 is already out there?
- arcbyte 9y ago
  As someone who thinks HTTP2 is garbage and refuses to support it in my enterprise, this is a good step towards a MUCH better solution.
  - avg_dev 9y ago
    I don't know much about HTTP2; why do you dislike it?
    - merb 9y ago
      one reason to dislike it, is because it is way too stateful. and a lot of things depends on timings. /and the spec misses some stuff, like if all my streams are done (except one long running stream, SSE, etc) and I get a new request what do do now? (there are multiple ways of doing that, one would be to just cancel the long running stream and hope that the client reconnects to the new connection). Personally I think it is more complex than it was needed to be. stream priority can also be a PITA. Ah and I basically forgot, due to the state it is practically not the best protocol for mobile clients over 2G/low end 3G. It's not the worst, I think h2 would be fine if it would be 10 years earlier, since I think we can learn a lot from the behavior of h2 in real world scenarios and than use the best things from http/1.1 and h2 to make h3.
      - styfle 9y ago
        I thought HTTP2 was born out of the experimental SPDY protocol which was used in the wild for quite some time, maybe 5 years. I think SPDY was released around 2010. HTTP2 is like the good parts of SPDY and what was learned over that time period (I think).
        9y ago
avg_dev 9y ago
Wow, I thought I knew basic HTTP but I don't know anything about preloading or prefetching or early hints. Time to read up.
- grzm 9y ago
  Don't beat yourself up too much. The document is marked "2017-10-30 (latest revision 2017-10-28)".
bluetwo 9y ago
Neat. Now how is this going to get abused?
- bluetwo 9y ago
  For instance, you could add this to a popular site to create a really easy DDOS attack on the target of your choice.
  - avg_dev 9y ago
    At first, I thought, "they must limit URLs to be relative" which would solve that issue, but a lot of sites use CDNs to host static assets, so I don't know.
  - TheCoreh 9y ago
    You could also add <link rel="stylesheet"> tags to achieve a similar effect, so it doesn't really introduce anything new
    - est 9y ago
      modify headers is way easier than parsing and messing with HTML.
    - bluetwo 9y ago
      It would be far more hidden in the headers.
cbsmith 9y ago
At some point we're just going to go with a full-on bidirectional stateful protocol, right? ;-)
- tzahola 9y ago
  And we could call it HTTCP
  - JetSpiegel 9y ago
    Or for branding, Websockets
  - sp332 9y ago
    HTPP - hypertext packet protocol
grandalf 9y ago
This seems to be meant as an AMP killer.
kardos 9y ago
Am I wrong in thinking that these hints should include subresource integrity hashes? Given hints with SRI hashes, the client can fetch/verify them and be ready when the HTML arrives, or even better, consult the cache and verify to avoid fetching and save bandwidth.
- CGamesPlay 9y ago
  Seems like it wouldn't really increase the speed at which the resources would be rejected, because the spec is that the resources can only be preloaded and not used: they are advisory messages only. So a compliant browser can take the hints, load the files, but only "use" them after seeing the HTML and validating the hash. Then a faster browser could compute that hash in advance, as well as precompiling the JS, etc.
- kevin_nisbet 9y ago
  So I think there are a couple aspects to consider on this. This RFC very strongly points to hints as the purpose, but to me appears to be generically implemented. So HTTP 103 can send any header, but only the final headers are authoritative. So it's really up to wherever those headers are defined to indicate what can/cannot be indicated by the headers. In other words, what a header can represent is likely a different discussion. Subresource integrity is actually a w3c recommendation and not an IETF recommendation, so the checksum doesn't appear to be conveyed through headers. But trying to think about it logically, I don't think it's necessary to have the hashes at this stage. The web browser get's a HTTP 103, and see's the link rel and begins requesting and caching the resource. The web browser then loads the HTML, which includes the subresource integrity, that it then uses to check the result it already downloaded and cached. To validate that resource, it would need to download it anyway, the only thing HTTP 103 did was allow the the content to start downloading sooner in the process.
  - Too 9y ago
    You don't need to download the file to verify the contents. The purpose of having a hash in the link is to allow you to cache jQuery previously downloaded from one CDN even though the link points to another.
mbell 9y ago
To explain the use case for this (as I understand it): http/2 push sounds great at first glance for doing things like sending your CSS/JS bundles downstream with the HTML. The problem with this is that only the system that builds the HTML knows what needs to be pushed and only the system terminating the http/2 connection can send the assets. That means your app servers would need to terminate the http/2 connection and would be serving static assets. Serving static assets from your app server sucks for a lot of reasons. Instead what you want to do is tell some upstream proxy that is good at serving static assets what it should push. This is done by having the upstream proxy parse the Link HTTP headers in the response, which many services already do. But, today they can't start pushing assets until the main response is being sent since they need the headers from it to instruct them. Ideally you'd start sending assets ASAP, while the app server is building the page. This is exactly what the 103 response is most useful for. e.g. You have a CDN front for your app servers, the app server sends an early 103 as soon as it knows what assets the page needs, the CDN intercepts this response and uses it to start pushing the assets to the client from the local edge node using http/2 push. This lets you benefit from http/2 push of your assets while processing the main response without your app server needing to serve static assets or even know about http/2 itself.
- pcl 9y ago
  Does HTTP2 support multiple concurrent streams over a single client connection? If not, presumably your use case would require that the client has a separate HTTP2 connection opened up to the CDN already, right? Or am I missing something?
  - mbell 9y ago
    In my example there would be only a single connection from the client, to the CDN edge. The CDN is acting as a reverse proxy for the main request and pulling Link headers out of the response(s) to decide what static assets to push to the client over the same connection.
    - pcl 9y ago
      I don't love the idea of routing all my app traffic through the CDN edge, and I really get the willies thinking about terminating app-tier SSL at the CDN. I guess if a deployment is all-AWS or something, sure, but there's plenty of static content that I'm comfortable sharing with my CDN even though I don't want them seeing any user-generated content or metadata.
andy_ppp 9y ago
Nice, not sure how trivial this will be to add to frameworks and still make it not as slow as two requests. I think maybe this could be a macro in Elixir’s Phoenix framework that’s done at compilation time; would mean it isn’t changeable at runtime but would make it very fast.
unmole 9y ago
It isn't yet approved. It is still a draft, not an RFC. Even if it does become an RFC, it is intended for the Experimental track, not the Standards track.
- bdamm 9y ago
  Good time to make sure clients are behaving correctly w.r.t. 1xx headers.
- TimTheTinker 9y ago
  The HN post title really should be changed. Folks skimming headlines will see what is, in effect, fake news.
photonios 9y ago
This is actually great. I ran into this problem recently. I wanted to push out some CSS while waiting for some external response. Unfortunately, it was very important to be able to send a 404 in case it turned out the external response. This means we had to live with a higher TFFB. Let’s hope this becomes widely adopted soon. Does anyone know how long it took till other HTTP features that were added later (not HTTP2) were widely supported?
- deleted 9y ago
  [deleted]
breakingcups 9y ago
This is one of those optimizations where I'm ambivalent about it's usefulness. Sure, Google might get a millisecond or two less in their apps, but who in their right mind has the engineering time to implement this very, very small optimization when there's many other things to be done that probably have a higher priority?
- mhotchen 9y ago
  With the article yesterday about the Trinet[1] I can see this optimization being used in the majority of HTTP traffic, even if it won't be used by a majority of companies/websites. [1] https://news.ycombinator.com/item?id=15584456 https://news.ycombinator.com/item?id=15584456
- xxs 9y ago
  "millisecond or two" won't cut it as the only usable case would happen when there is non-trivial delay between 103 and 200 statuses. Also I see this as more harmful than good as it'd require yet another packet sent and ack'd.
  - Too 9y ago
    I also fail to see the usefulness. A server can already today send only the html head, flush the stream then pause before sending the body? Most modern SPAs also have a static index.html which shouldn't take long to serve anyway. This is going to be abused by cargo cult brogrammers who heard that "103 will make your site faster!!!1" and put every single resource as a 103 making the time to 200 even longer than the time you actually potentily gain.
- dsign 9y ago
  You are right, most people don't have the engineering time to implement this. Though there is definitely a market for this kind of optimizations in a SaaS solution (I know that because it has something to do with my job)... Now, implementation of this by browsers is going to take a long time, and then we will see incompatibilities trickle down all the way, with Safari taking a few years after everybody else has it and IE/Edge also taking forever.... I should rather work in a farm and harvest tomatoes...
pebers 9y ago
Are there any prior examples of sending multiple status codes in one response? I didn't think you could, but there's not much discussion of it in the draft (a little in section 3 only) which makes me think it's not seen as controversial. Seems like it'd be a heap of work to update all the servers and clients out there if it's not supported already?
- aexaey 9y ago
  Yes. "100 Continue". [1] If client intends to send a POST request with request body large enough to try to avoid wasting bandwidth (in case server might reply with 3xx,4xx or 5xx), the client will send only headers including "Expect: 100-continue" header, then server indenting to reply with "200 OK", will instead first reply with "100 Continue" than client will send POST body, and finally server sends "200 OK". [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3 https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8....
- xg15 9y ago
  All 1xx responses are supposed to be sent like this - though "all" doesn't mean much as I think only two (100, 101) are defined in HTTP. Other derived protocols (e.g. WEBDAV) have additional ones though. Also the exchange seems to be subtly different for each of them: 100 Continue: Client sends start of request, server sends 100, client sends rest of request. 101 Switching Protocols: Client sends request, server sends 101, client sends non-http request. 103 Early Hints: Client sends request, server sends 103, server sends response.
bagswatchesus 9y ago
Consult the cache and verify to avoid fetching and save bandwidth. http://www.sellbagswallets.com/wallets-and-purses http://www.sellbagswallets.com/wallets-and-purses
jijji 9y ago
why not just add a "preload" flag to the style or link tag, this looks like a lot of extra work.
buro9 9y ago
What happens to a Set-Cookie on a 103? What happens to hints in a redirect chain?, i.e. 301 103 301 103 200 What headers are applicable to the 103 beyond Link? If a 103 included Refresh, could this be used like a timeout (redirect after Refresh time if actual request did not respond?) This... > A server MAY use a 103 (Early Hints) response to indicate only some of the header fields that are expected to be found in the final response. ... implies that all possible HTTP headers from the final response may be in the 103. RFCs need less ambiguity, lest clients and servers start to fill in the gaps and have divergent behaviour.
- sp332 9y ago
  If the implementation decided to honor Set-Cookie in a 301, it should use the same security boundaries that it would use anywhere else. For a redirect chain and the rest, again it's up to the implementation. Since this is just an optional optimization, does it matter if there are divergent clients and servers?
tenderlove 9y ago
The author of this draft is also the author of H2O (an HTTP/2 webserver). IMO the cool thing about this RFC is that you can put an HTTP/2 proxy that understands Early Hints in front of an HTTP/1 application server, and give the application server HTTP/2 push without needing to "HTTP/2 enable" the application server. We added early hints support to Puma: https://github.com/puma/puma/pull/1403 https://github.com/puma/puma/pull/1403 Then added early hints to Rails: https://github.com/rails/rails/pull/30744 https://github.com/rails/rails/pull/30744 Such that if you run H2O (or any webserver that supports early hints) in front of Rails, you can get asset push support for free. eileencodes wrote a great blog post about her work on this: http://eileencodes.com/posts/http2-early-hints/ http://eileencodes.com/posts/http2-early-hints/
psadri 9y ago
Browsers can learn this on their own and start prefetching likely resources before the server responds. Like a cpu's branch prediction. I wouldn't be surprised if chrome already did this.
vipkhan 9y ago
I guess it is related to preloading? Not quite getting the purpose.

417 points by snomad 9y ago

This look nice to prefetch some stuff, although i have a feeling it'll break some not-so-nicely coded HTTP 1.1 clients that expect everything after the first CR/LF to be the content or -more likely- if the response isn't 200 for the request to fail :-P.

toast0 9y ago

This seems like it's only of interest if you need to do time consuming processing before deciding what http status code to send, because once you pick the status code, you can send it and start sending the rest of the headers. Is it common to serve something other than http 200 and to take a long time to do it -- but also be able to send something early sooner? Most of the the slow pages I've worked on were either slow to load all the details, but I knew it was 200 near instantly, and could get all the headers and the HTML head out pretty quickly, or had some structural problems that made them terribly slow, but we couldn't get anything out quickly anyway.

xxs 9y ago
The vast majority of the cases the status would be planned as 200... unless for whatever reason a timeout/error occurs during process. Then it may end up with error status and or redirect to an error handling page. Still very dubious proposal with minimal benefit(s).

tyingq 9y ago

Shouldn't it have a complimentary "denied" code? Or is 403 "Forbidden" the complement? Or maybe 401 "Unauthorized"? I guess it is related to preloading? Not quite getting the purpose. Edit: ahh, the complete story is here: https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-05 https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-0... (fixed). Note that someone fixed the capitalized "A" in "approved" in the title. It confused my initial reading of the article.

matthewbauer 9y ago
Yeah, the actual name is "103 Early Hints" not "103 Approved".
- helb 9y ago
  I guess the title was meant as "… Approved as new status code", not "HTTP 103 Approved …". A bit unfortunate wording (and that capital A).
alexbecker 9y ago
As I understand it, the status code would improve performance in situations like the following: 1. Client requests X.html (which requires Y.css and Z.js) from Proxy. 2. Proxy forwards client's X.html request to Server. 3. [Server takes a long time to respond] 4. Server sends a 200 response to Proxy with X.html. 5. Proxy, per some configuration, adds Preload headers to this response indicating that Y.css and Z.js should be immediately loaded once this response is received, and sends it to Client. 6. Client requests Y.css and Z.js. With the 103 status code, this would look like: 1. Client requests X.html (which requires Y.css and Z.js) from Proxy. 2. Proxy forwards client's X.html request to server and, per some configuration, immediately sends a 103 response with Preload headers for Y.css and Z.js to Client. 3. [Server takes a long time to respond] 4. In parallel, Client requests Y.css and Z.js. 5. Server sends a 200 response to Proxy with X.html. 6. Proxy sends this response to Client. Note that since Y.css and Z.js are requested sooner, the final load time should be less.
- stock_toaster 9y ago
  The proxy could also read preload headers from the Server, and start preemptively fetching Y.css and Z.js from the Server at the same time (step 2) it forwards the preload headers back to Client.
itaris 9y ago
Someone only read the headline.

richdougherty 9y ago

Summary: a new status code that lets the server send headers early, before the main headers. This helps with optimisations like preloading. Example from the document: HTTP/1.1 103 Early Hints Link: </main.css>; rel=preload; as=style 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: </main.css>; rel=preload; as=style Link: </newstyle.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script The client can start preloading the CSS and JavaScript before the main headers arrive. This is a nice optimisation. There are various security risks with sending multiple headers to non-conforming clients hence: "Therefore, a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly."

tbodt 9y ago
Sounds a lot like HTTP/2 push.
- deleted 9y ago
  [deleted]
- scott_karana 9y ago
  From the RFC intro: > HTTP/2 ([RFC7540]) server push can accelerate the delivery of resources, but only resources for which the server is authoritative. The other limitation of server push is that the response will be transmitted regardless of whether the client has the response cached. At the cost of spending one extra round-trip compared to server push in the worst case, delivering Link header fields in a timely fashion is more flexible and might consume less bandwidth.
  - mozumder 9y ago
    There are cache-aware HTTP2 server push technologies that can be used to cut that down wasted bandwidth. See: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http...

_justinfunk 9y ago

Title should probably be changed to have a lowercase "approved". It's a little misleading as-is.

scott_karana 9y ago
Agreed! I was confused when it was 103 Early Hints Not 103 Approved

edoceo 9y ago

Waiting for https://http.cat/103 https://http.cat/103 to be updated

Animats 9y ago

Can this be abused by middleboxes to stick in an interstitial ad before and during page load?

dotancohen 9y ago
Though other posters have pointed out why this is not the case, it _will_ make DDOS-by-linking much easier for "middleboxes" to orchestrate. I'm sure that there are further security issues to be found, as there are with all new technologies.
DiabloD3 9y ago
No, its pretty much only useful for hinting css and js files that will be loaded in the <head>.
- rhizome 9y ago
  so...JS injection then?
  - traek 9y ago
    No. The JS would still be need to referenced by the page, this just affects preloading of assets.
    - rhizome 9y ago
      So a far-side check, but does it not execute it until everything checks out? Y'know, now that I think about it more.
      - vertex-four 9y ago
        It literally just says "please download this into the browser cache". Nothing happens to things in the browser cache - they certainly don't get executed. Later, if a page tries to load resources, it might come from the browser cache.

acdha 9y ago

Has anyone looked into implementing this with Varnish? It seems like a great way to handle non-streaming backend servers.

fiatjaf 9y ago

Isn't this way too complicated to define and implement considering that HTTP/2 is already out there?

arcbyte 9y ago
As someone who thinks HTTP2 is garbage and refuses to support it in my enterprise, this is a good step towards a MUCH better solution.
- avg_dev 9y ago
  I don't know much about HTTP2; why do you dislike it?
  - merb 9y ago
    one reason to dislike it, is because it is way too stateful. and a lot of things depends on timings. /and the spec misses some stuff, like if all my streams are done (except one long running stream, SSE, etc) and I get a new request what do do now? (there are multiple ways of doing that, one would be to just cancel the long running stream and hope that the client reconnects to the new connection). Personally I think it is more complex than it was needed to be. stream priority can also be a PITA. Ah and I basically forgot, due to the state it is practically not the best protocol for mobile clients over 2G/low end 3G. It's not the worst, I think h2 would be fine if it would be 10 years earlier, since I think we can learn a lot from the behavior of h2 in real world scenarios and than use the best things from http/1.1 and h2 to make h3.
    - styfle 9y ago
      I thought HTTP2 was born out of the experimental SPDY protocol which was used in the wild for quite some time, maybe 5 years. I think SPDY was released around 2010. HTTP2 is like the good parts of SPDY and what was learned over that time period (I think).
      - 9y ago

avg_dev 9y ago

Wow, I thought I knew basic HTTP but I don't know anything about preloading or prefetching or early hints. Time to read up.

grzm 9y ago
Don't beat yourself up too much. The document is marked "2017-10-30 (latest revision 2017-10-28)".

bluetwo 9y ago

Neat. Now how is this going to get abused?

bluetwo 9y ago
For instance, you could add this to a popular site to create a really easy DDOS attack on the target of your choice.
- avg_dev 9y ago
  At first, I thought, "they must limit URLs to be relative" which would solve that issue, but a lot of sites use CDNs to host static assets, so I don't know.
- TheCoreh 9y ago
  You could also add <link rel="stylesheet"> tags to achieve a similar effect, so it doesn't really introduce anything new
  - est 9y ago
    modify headers is way easier than parsing and messing with HTML.
  - bluetwo 9y ago
    It would be far more hidden in the headers.

cbsmith 9y ago

At some point we're just going to go with a full-on bidirectional stateful protocol, right? ;-)

tzahola 9y ago
And we could call it HTTCP
- JetSpiegel 9y ago
  Or for branding, Websockets
- sp332 9y ago
  HTPP - hypertext packet protocol

grandalf 9y ago

This seems to be meant as an AMP killer.

kardos 9y ago

Am I wrong in thinking that these hints should include subresource integrity hashes? Given hints with SRI hashes, the client can fetch/verify them and be ready when the HTML arrives, or even better, consult the cache and verify to avoid fetching and save bandwidth.

CGamesPlay 9y ago
Seems like it wouldn't really increase the speed at which the resources would be rejected, because the spec is that the resources can only be preloaded and not used: they are advisory messages only. So a compliant browser can take the hints, load the files, but only "use" them after seeing the HTML and validating the hash. Then a faster browser could compute that hash in advance, as well as precompiling the JS, etc.
kevin_nisbet 9y ago
So I think there are a couple aspects to consider on this. This RFC very strongly points to hints as the purpose, but to me appears to be generically implemented. So HTTP 103 can send any header, but only the final headers are authoritative. So it's really up to wherever those headers are defined to indicate what can/cannot be indicated by the headers. In other words, what a header can represent is likely a different discussion. Subresource integrity is actually a w3c recommendation and not an IETF recommendation, so the checksum doesn't appear to be conveyed through headers. But trying to think about it logically, I don't think it's necessary to have the hashes at this stage. The web browser get's a HTTP 103, and see's the link rel and begins requesting and caching the resource. The web browser then loads the HTML, which includes the subresource integrity, that it then uses to check the result it already downloaded and cached. To validate that resource, it would need to download it anyway, the only thing HTTP 103 did was allow the the content to start downloading sooner in the process.
- Too 9y ago
  You don't need to download the file to verify the contents. The purpose of having a hash in the link is to allow you to cache jQuery previously downloaded from one CDN even though the link points to another.

mbell 9y ago

To explain the use case for this (as I understand it): http/2 push sounds great at first glance for doing things like sending your CSS/JS bundles downstream with the HTML. The problem with this is that only the system that builds the HTML knows what needs to be pushed and only the system terminating the http/2 connection can send the assets. That means your app servers would need to terminate the http/2 connection and would be serving static assets. Serving static assets from your app server sucks for a lot of reasons. Instead what you want to do is tell some upstream proxy that is good at serving static assets what it should push. This is done by having the upstream proxy parse the Link HTTP headers in the response, which many services already do. But, today they can't start pushing assets until the main response is being sent since they need the headers from it to instruct them. Ideally you'd start sending assets ASAP, while the app server is building the page. This is exactly what the 103 response is most useful for. e.g. You have a CDN front for your app servers, the app server sends an early 103 as soon as it knows what assets the page needs, the CDN intercepts this response and uses it to start pushing the assets to the client from the local edge node using http/2 push. This lets you benefit from http/2 push of your assets while processing the main response without your app server needing to serve static assets or even know about http/2 itself.

pcl 9y ago
Does HTTP2 support multiple concurrent streams over a single client connection? If not, presumably your use case would require that the client has a separate HTTP2 connection opened up to the CDN already, right? Or am I missing something?
- mbell 9y ago
  In my example there would be only a single connection from the client, to the CDN edge. The CDN is acting as a reverse proxy for the main request and pulling Link headers out of the response(s) to decide what static assets to push to the client over the same connection.
  - pcl 9y ago
    I don't love the idea of routing all my app traffic through the CDN edge, and I really get the willies thinking about terminating app-tier SSL at the CDN. I guess if a deployment is all-AWS or something, sure, but there's plenty of static content that I'm comfortable sharing with my CDN even though I don't want them seeing any user-generated content or metadata.

andy_ppp 9y ago

Nice, not sure how trivial this will be to add to frameworks and still make it not as slow as two requests. I think maybe this could be a macro in Elixir’s Phoenix framework that’s done at compilation time; would mean it isn’t changeable at runtime but would make it very fast.

unmole 9y ago

It isn't yet approved. It is still a draft, not an RFC. Even if it does become an RFC, it is intended for the Experimental track, not the Standards track.

bdamm 9y ago
Good time to make sure clients are behaving correctly w.r.t. 1xx headers.
TimTheTinker 9y ago
The HN post title really should be changed. Folks skimming headlines will see what is, in effect, fake news.

photonios 9y ago

This is actually great. I ran into this problem recently. I wanted to push out some CSS while waiting for some external response. Unfortunately, it was very important to be able to send a 404 in case it turned out the external response. This means we had to live with a higher TFFB. Let’s hope this becomes widely adopted soon. Does anyone know how long it took till other HTTP features that were added later (not HTTP2) were widely supported?

deleted 9y ago
[deleted]

breakingcups 9y ago

This is one of those optimizations where I'm ambivalent about it's usefulness. Sure, Google might get a millisecond or two less in their apps, but who in their right mind has the engineering time to implement this very, very small optimization when there's many other things to be done that probably have a higher priority?

mhotchen 9y ago
With the article yesterday about the Trinet[1] I can see this optimization being used in the majority of HTTP traffic, even if it won't be used by a majority of companies/websites. [1] https://news.ycombinator.com/item?id=15584456 https://news.ycombinator.com/item?id=15584456
xxs 9y ago
"millisecond or two" won't cut it as the only usable case would happen when there is non-trivial delay between 103 and 200 statuses. Also I see this as more harmful than good as it'd require yet another packet sent and ack'd.
- Too 9y ago
  I also fail to see the usefulness. A server can already today send only the html head, flush the stream then pause before sending the body? Most modern SPAs also have a static index.html which shouldn't take long to serve anyway. This is going to be abused by cargo cult brogrammers who heard that "103 will make your site faster!!!1" and put every single resource as a 103 making the time to 200 even longer than the time you actually potentily gain.
dsign 9y ago
You are right, most people don't have the engineering time to implement this. Though there is definitely a market for this kind of optimizations in a SaaS solution (I know that because it has something to do with my job)... Now, implementation of this by browsers is going to take a long time, and then we will see incompatibilities trickle down all the way, with Safari taking a few years after everybody else has it and IE/Edge also taking forever.... I should rather work in a farm and harvest tomatoes...

pebers 9y ago

Are there any prior examples of sending multiple status codes in one response? I didn't think you could, but there's not much discussion of it in the draft (a little in section 3 only) which makes me think it's not seen as controversial. Seems like it'd be a heap of work to update all the servers and clients out there if it's not supported already?

aexaey 9y ago
Yes. "100 Continue". [1] If client intends to send a POST request with request body large enough to try to avoid wasting bandwidth (in case server might reply with 3xx,4xx or 5xx), the client will send only headers including "Expect: 100-continue" header, then server indenting to reply with "200 OK", will instead first reply with "100 Continue" than client will send POST body, and finally server sends "200 OK". [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3 https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8....
xg15 9y ago
All 1xx responses are supposed to be sent like this - though "all" doesn't mean much as I think only two (100, 101) are defined in HTTP. Other derived protocols (e.g. WEBDAV) have additional ones though. Also the exchange seems to be subtly different for each of them: 100 Continue: Client sends start of request, server sends 100, client sends rest of request. 101 Switching Protocols: Client sends request, server sends 101, client sends non-http request. 103 Early Hints: Client sends request, server sends 103, server sends response.

bagswatchesus 9y ago

Consult the cache and verify to avoid fetching and save bandwidth. http://www.sellbagswallets.com/wallets-and-purses http://www.sellbagswallets.com/wallets-and-purses

jijji 9y ago

why not just add a "preload" flag to the style or link tag, this looks like a lot of extra work.

buro9 9y ago

What happens to a Set-Cookie on a 103? What happens to hints in a redirect chain?, i.e. 301 103 301 103 200 What headers are applicable to the 103 beyond Link? If a 103 included Refresh, could this be used like a timeout (redirect after Refresh time if actual request did not respond?) This... > A server MAY use a 103 (Early Hints) response to indicate only some of the header fields that are expected to be found in the final response. ... implies that all possible HTTP headers from the final response may be in the 103. RFCs need less ambiguity, lest clients and servers start to fill in the gaps and have divergent behaviour.

sp332 9y ago
If the implementation decided to honor Set-Cookie in a 301, it should use the same security boundaries that it would use anywhere else. For a redirect chain and the rest, again it's up to the implementation. Since this is just an optional optimization, does it matter if there are divergent clients and servers?

tenderlove 9y ago

The author of this draft is also the author of H2O (an HTTP/2 webserver). IMO the cool thing about this RFC is that you can put an HTTP/2 proxy that understands Early Hints in front of an HTTP/1 application server, and give the application server HTTP/2 push without needing to "HTTP/2 enable" the application server. We added early hints support to Puma: https://github.com/puma/puma/pull/1403 https://github.com/puma/puma/pull/1403 Then added early hints to Rails: https://github.com/rails/rails/pull/30744 https://github.com/rails/rails/pull/30744 Such that if you run H2O (or any webserver that supports early hints) in front of Rails, you can get asset push support for free. eileencodes wrote a great blog post about her work on this: http://eileencodes.com/posts/http2-early-hints/ http://eileencodes.com/posts/http2-early-hints/

psadri 9y ago

Browsers can learn this on their own and start prefetching likely resources before the server responds. Like a cpu's branch prediction. I wouldn't be surprised if chrome already did this.

vipkhan 9y ago

I guess it is related to preloading? Not quite getting the purpose.