3 ms·

> While I disagree with mbell's interpretation of the value of this header or how it could be used FWIW the use case I'm describing has already been added to R

by mbell 9y ago

> While I disagree with mbell's interpretation of the value of this header or how it could be used FWIW the use case I'm describing has already been added to Rails / Puma: http://eileencodes.com/posts/http2-early-hints/ http://eileencodes.com/posts/http2-early-hints/ https://github.com/rails/rails/pull/30744 https://github.com/rails/rails/pull/30744 https://github.com/puma/puma/pull/1403 https://github.com/puma/puma/pull/1403

kevin_nisbet 9y ago
Sorry, I apologize for being unclear, I don't agree with you're interpretation of the use case that adds the most value. While the RFC does state that what you described can happen at a caching intermediary, I don't believe that's where the value lies or the primary use case. To me, much of the value added is to get the 103 to the client early, and allow it to begin making decisions on whether the content is in it's local cache, or to begin making requests to third party servers. This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache. It's a balancing act of course, but if the resource being pushed is above a certain size, pushing the resource on each request could add overhead, not reduce it.
- mbell 9y ago
  The problem is that clients won't be supporting 103 for a long time, I would guess it'll be 3-5 years before you can realistically push the 103 to a browser and I don't thank any currently support it. It's also not a particularly safe thing to turn on. e.g. Chrome prior to 57 bombed on http/2 connections that sent a 103 which is in contrast to the RFP's theory that http/2 clients should be 'safer' in handling it than http/1 clients. We really don't know how many clients and proxies will have trouble with 103 and have to wait for the vast majority to at least ignore it / pass it along before it could be turned on externally. > This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache. When a server sends a push to the client it first sends `PUSH_PROMISE` command to the client and the client may cancel the push, e.g. if it already has the asset in cache based on url. Assuming things move forward the server sends a HEADERS frame which can also trigger to the client to cancel the push, e.g. in response to an etag, though at this point some DATA frames may be in flight. You are correct that you can't push assets for another domain, but I don't see this as much of a problem as there are many other benefits to having all requests go a CDN/reverse proxy that can handle the static asset serving, like regional SSL termination. There are of course third party scripts that may be needed, but it's good practice make these non-blocking for page rendering anyway so if they are a bit behind that is probably ok, if not preferable.

by mbell 9y ago

kevin_nisbet 9y ago

Sorry, I apologize for being unclear, I don't agree with you're interpretation of the use case that adds the most value. While the RFC does state that what you described can happen at a caching intermediary, I don't believe that's where the value lies or the primary use case. To me, much of the value added is to get the 103 to the client early, and allow it to begin making decisions on whether the content is in it's local cache, or to begin making requests to third party servers. This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache. It's a balancing act of course, but if the resource being pushed is above a certain size, pushing the resource on each request could add overhead, not reduce it.

mbell 9y ago
The problem is that clients won't be supporting 103 for a long time, I would guess it'll be 3-5 years before you can realistically push the 103 to a browser and I don't thank any currently support it. It's also not a particularly safe thing to turn on. e.g. Chrome prior to 57 bombed on http/2 connections that sent a 103 which is in contrast to the RFP's theory that http/2 clients should be 'safer' in handling it than http/1 clients. We really don't know how many clients and proxies will have trouble with 103 and have to wait for the vast majority to at least ignore it / pass it along before it could be turned on externally. > This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache. When a server sends a push to the client it first sends `PUSH_PROMISE` command to the client and the client may cancel the push, e.g. if it already has the asset in cache based on url. Assuming things move forward the server sends a HEADERS frame which can also trigger to the client to cancel the push, e.g. in response to an etag, though at this point some DATA frames may be in flight. You are correct that you can't push assets for another domain, but I don't see this as much of a problem as there are many other benefits to having all requests go a CDN/reverse proxy that can handle the static asset serving, like regional SSL termination. There are of course third party scripts that may be needed, but it's good practice make these non-blocking for page rendering anyway so if they are a bit behind that is probably ok, if not preferable.