rfc:cli_server_http2

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:cli_server_http2 [2016/01/08 21:26]
davey
rfc:cli_server_http2 [2017/09/22 13:28] (current)
Line 13: Line 13:
 ===== Proposal ===== ===== Proposal =====
  
-For supporting HTTP/2, it is pretty well agreed ((see references)) that we should use a third party library to implement it, with libnghttp2 being my proposed suggestion. While HTTP/can function without SSL support (TLS), no browser implementation supports this — this change therefore also requires an SSL library (probably openssl, as we already support it).+For supporting HTTP/2, it is pretty well agreed ((see references)) that we should use a third party library to implement it, with libnghttp2 being my proposed suggestion. We should ship with some self signed certs (it's for development only, remember!) that can be used to setup SSL, as no browser supports plain text HTTP/2.
  
-Given that this introduces two new required dependencies there are two ways we can implement this functionality:+Given that this introduces new required dependency there are two ways we can implement this functionality:
  
-  - Make it optional, allowing you to build the current HTTP/1.x cli-server and requiring no additional dependencies +  - Make it optional, allowing you to build the current HTTP/1.x cli-server and requiring no additional dependency 
-  - Make it required+  - Make it required, but this also effectively requires libopenssl
  
-It should be noted that libnghttp2 is also used by curland therefore if you're doing HTTP/work and have curl, you already have it.+It should be noted that libnghttp2 is also used by both curl and Apache 2, making it more likely that you already have it
  
 With either implementation, we can also make HTTP/2 always enabled (if built in), or we can make it de/activated with a flag, such as: ''--[no-]http2''. I believe we **should** have this flag as it makes it possible to test HTTP/1.x fallback for HTTP/2 clients, as well as HTTP/2. With either implementation, we can also make HTTP/2 always enabled (if built in), or we can make it de/activated with a flag, such as: ''--[no-]http2''. I believe we **should** have this flag as it makes it possible to test HTTP/1.x fallback for HTTP/2 clients, as well as HTTP/2.
Line 26: Line 26:
 In addition, we should consider adding the HTTP/2 ''SETTINGS'' to ''$_SERVER'' so we can both detect that the request is using HTTP/2 and make intelligent decisions on how the application performs (e.g. server push of multiple CSS files vs minifying/concatenating). In addition, we should consider adding the HTTP/2 ''SETTINGS'' to ''$_SERVER'' so we can both detect that the request is using HTTP/2 and make intelligent decisions on how the application performs (e.g. server push of multiple CSS files vs minifying/concatenating).
  
-We should also support the ability to do server push using HTTP headers (current community thinking is leaning towards ''Link: <resource>; rel=push'' header)+We should also support the ability to do server push using HTTP headers (current community thinking is leaning towards ''Link: <resource>; rel=preload'' header)
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
-If we make this required for cli-server, then the new dependency requirements could be considered a BC break+If we make this required for cli-server, then the new dependency requirement could be considered a BC break
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
Line 38: Line 38:
 ===== RFC Impact ===== ===== RFC Impact =====
  
-Adds two newly required dependenciesand their dependencies+Adds newly required dependencylibnghttp2
  
 ==== To SAPIs ==== ==== To SAPIs ====
rfc/cli_server_http2.1452288363.txt.gz · Last modified: 2017/09/22 13:28 (external edit)