8 ms·

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 doc

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...
- jaffathecake 9y ago
  Although HTTP/2 PUSH_PROMISE is a lot more complicated for developers: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though...
mabbo 9y ago
Trying to wrap my head around this. The server is going to be slowly building up a real reply. But it also knows that most likely, the real reply is going to need a list of assets that doesn't change regardless of what the reply is. So to save time, the server is going to spit out a few packets early that say "Hey, while you're waiting on me, go load these". Am I understanding this right? It's like your server at the restaurant bringing you appetizers early because they're fast to cook and you were just going to be sitting there doing nothing anyways.
- chrismorgan 9y ago
  Generally correct. However, the the final response won’t necessarily actually include those headers, so it’s more that the server is saying, “I think you’ll get this, but don’t quote me on it”. In the case of a Link header, it would thus be OK to fetch the resources, and if you don’t end up needing them, c’est la vie. In the case of CSS, it’d be perfectly legitimate to load the CSS in anticipation. It would even be OK to execute JavaScript up to the point of its needing to interact with the document or HTTP. But it would be not OK to execute anything that was not safe (in the terminology of the HTTP spec on methods). I’d extend your parallel in appetisers, but it gets mildly disturbing quite quickly.
  - jaxn 9y ago
    So like the server bringing you a glass of water and basket of bread that you may or may not want, but most people do so the odds are good enough.
    - brian_cloutier 9y ago
      the parent was implying that the server might later change their mind and ask for the water and bread back, so you shouldn't do anything irreversible with it.
      - csours 9y ago
        In the interest of clobbering the analogy even further: It would be like the server bringing you a red wine and then serving fish - the red wine doesn't go with it, so you better hope you can get it off the table and the taste out of your mouth.
leggomylibro 9y ago
So is there a default header to say 'I support 103s' or 'here are my extended capabilities'? Or are we just going to have every API ask for 'x-<company>-preload: true'?
- colanderman 9y ago
  From [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." They don't need to be requested. Supporting servers will just send them, unsupporting clients will just ignore them (barring the potential security issue with broken HTTP/1.1 implementations which is noted in the 103 spec). [1] https://tools.ietf.org/html/rfc7231#section-6.2 https://tools.ietf.org/html/rfc7231#section-6.2
- xg15 9y ago
  For HTTP 100, there is the Expect: header to indicate capability. I think it would make sense to use it here as well.
est 9y ago
This in general is a terrible idea IMHO I use tabix.ui for Clickhouse, clickhouse generates tons of extra headers as progress bars. Chrome will just cut the connection and says header too large error. http 103 will just be abused like that. People will make megabytes sized headers
- bdamm 9y ago
  Not likely. Megabyte sized headers would significantly degrade the loading performance of the web site since the browser can't go on to begin fetching the main content until the headers have arrived. So, operators that don't care for performance might abuse it, but then why would they bother at all?
- acdha 9y ago
  Wouldn't that same logic mean that we can't have JavaScript, CSS, image/audio/video, etc. because some people will send too much junk? We can't prevent people from using the web badly but anyone who doesn't completely disregard the user experience will be subject to the usual feedback loop.
deleted 9y ago
[deleted]
maxpert 9y ago
No! It's your pizza delivery service sending you menu of appetizers, because pizza is not ready yet. Oh! BTW you might not get this menu incase of traffic jam (aka buffering proxies), and pizza might arrive with menu as well :D.
xxs 9y ago
Just saying: you'd need to have the socket with tcp_nodelay for this to actually work.

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...
jaffathecake 9y ago
Although HTTP/2 PUSH_PROMISE is a lot more complicated for developers: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

mabbo 9y ago

Trying to wrap my head around this. The server is going to be slowly building up a real reply. But it also knows that most likely, the real reply is going to need a list of assets that doesn't change regardless of what the reply is. So to save time, the server is going to spit out a few packets early that say "Hey, while you're waiting on me, go load these". Am I understanding this right? It's like your server at the restaurant bringing you appetizers early because they're fast to cook and you were just going to be sitting there doing nothing anyways.

chrismorgan 9y ago
Generally correct. However, the the final response won’t necessarily actually include those headers, so it’s more that the server is saying, “I think you’ll get this, but don’t quote me on it”. In the case of a Link header, it would thus be OK to fetch the resources, and if you don’t end up needing them, c’est la vie. In the case of CSS, it’d be perfectly legitimate to load the CSS in anticipation. It would even be OK to execute JavaScript up to the point of its needing to interact with the document or HTTP. But it would be not OK to execute anything that was not safe (in the terminology of the HTTP spec on methods). I’d extend your parallel in appetisers, but it gets mildly disturbing quite quickly.
- jaxn 9y ago
  So like the server bringing you a glass of water and basket of bread that you may or may not want, but most people do so the odds are good enough.
  - brian_cloutier 9y ago
    the parent was implying that the server might later change their mind and ask for the water and bread back, so you shouldn't do anything irreversible with it.
    - csours 9y ago
      In the interest of clobbering the analogy even further: It would be like the server bringing you a red wine and then serving fish - the red wine doesn't go with it, so you better hope you can get it off the table and the taste out of your mouth.

leggomylibro 9y ago

So is there a default header to say 'I support 103s' or 'here are my extended capabilities'? Or are we just going to have every API ask for 'x-<company>-preload: true'?

colanderman 9y ago
From [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." They don't need to be requested. Supporting servers will just send them, unsupporting clients will just ignore them (barring the potential security issue with broken HTTP/1.1 implementations which is noted in the 103 spec). [1] https://tools.ietf.org/html/rfc7231#section-6.2 https://tools.ietf.org/html/rfc7231#section-6.2
xg15 9y ago
For HTTP 100, there is the Expect: header to indicate capability. I think it would make sense to use it here as well.

est 9y ago

This in general is a terrible idea IMHO I use tabix.ui for Clickhouse, clickhouse generates tons of extra headers as progress bars. Chrome will just cut the connection and says header too large error. http 103 will just be abused like that. People will make megabytes sized headers

bdamm 9y ago
Not likely. Megabyte sized headers would significantly degrade the loading performance of the web site since the browser can't go on to begin fetching the main content until the headers have arrived. So, operators that don't care for performance might abuse it, but then why would they bother at all?
acdha 9y ago
Wouldn't that same logic mean that we can't have JavaScript, CSS, image/audio/video, etc. because some people will send too much junk? We can't prevent people from using the web badly but anyone who doesn't completely disregard the user experience will be subject to the usual feedback loop.

deleted 9y ago

[deleted]

maxpert 9y ago

No! It's your pizza delivery service sending you menu of appetizers, because pizza is not ready yet. Oh! BTW you might not get this menu incase of traffic jam (aka buffering proxies), and pizza might arrive with menu as well :D.

xxs 9y ago

Just saying: you'd need to have the socket with tcp_nodelay for this to actually work.