Jean-Frederic, On 9/25/15 7:58 AM, jean-frederic clere wrote: > On 09/25/2015 10:51 AM, Rémy Maucherat wrote: >> 2015-09-25 9:29 GMT+02:00 Mark Thomas <ma...@apache.org>: >> >>> I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The >>> HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this, >>> there has been work to try and layer WebSocket on top of HTTP/2. >>> >>> At this point in time proxying WebSocket is tricky. httpd's WebSocket >>> proxy support makes assumptions that aren't always valid. >>> >>> General support for proxying HTTP upgrade would be a good thing and >>> right now AJP looks like the simplest way for us to make this happen. >>> >>> Most likely a HTTP/2 proxy will still be a legacy HTTP/1.1 proxy as >>> well. >> The main problem with the AJP.next plan is that by the time you release >> something many will be using HTTP/2. HTTP/2 is more important than the >> rest >> moving forward, and encapsulating in AJP it would likely be inefficient >> (basically, zillions of messages). >> >> OTOH, reversing the problem, AJP.next can be a HTTP/2 transport where you >> specify encapsulation of HTTP/1.1 and its upgrade. That could be more >> transparent and make configuration much cooler: unless the Tomcat >> connector >> gets some encapsulated requests, it could still act as a normal HTTP/2 >> connector. > > Basically HTTP/2 requires SSL: the proxies are doing the TLS/SSL > termination and send HTTP/1.1 (or AJP) to the back-ends, you can't > upgrade for the back-end. > > If the proxy would only do the TLS/SSL termination then you need > something like HTTP/2 protocol between the back-end and the proxy. > I think a customized HTTP/2 connector could do that, so there is no need > of AJP+ protocol.
In general, I think that the proposal to abandon AJP and use HTTP/2 instead makes a lot of sense. However, AJP still does offer an advantage over HTTP/1 or HTTP/2: it allows information to be passed out-of-band with respect to the message itself that can be considered trusted. Two good examples are the TLS information from the client's actual connection and any "shared-secret" for the connection. If using HTTP/[12], that information would have to be transferred in the HTTP headers which means that everything must be carefully-configured to block those headers from coming from the client. With AJP, you don't have to worry. Another possibility for using HTTP would be to use the headers, but to crypto-sign the header values, but nobody wants their proxies doing more crypto than necessary. > If you think of upgrade to websockets it is for already existing > applications and there proxying isn't that good (mod_proxy_wstunnel is > just a tunnel it doesn't care about the contents once upgraded). So > adding upgrade to AJP won't help much. > > Additionally I think websockets via upgrade is dead, there won't be new > developments there. > > I would just let AJP dying in peace. -chris
signature.asc
Description: OpenPGP digital signature
