> On 6 Jan 2016, at 20:06, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > > >> On 6 Jan 2016, at 10:19 PM, Cory Benfield <c...@lukasa.co.uk> wrote: >> >> >>> On 6 Jan 2016, at 09:48, Graham Dumpleton <graham.dumple...@gmail.com> >>> wrote: >>> >>> If this does solve the push issue, what is there in HTTP/2 then that one >>> couldn’t do via the existing WSGI interface? >> >> Well, plenty, but none that we’d *want* to expose via WSGI with the possible >> exception of long-running bi-directional communications channels like >> Websockets, which you’ve already expressed a desire to expose in a different >> API. =) > > Can you elaborate more on the ‘plenty’ part. > > This was the issue in the past. People appeared to want access to everything. > Thus why the belief you may as well allow them a separate API purpose built > for it. Maybe people are becoming more realistic in expectations now as to > what they really need for a typical web application as HTTP/2 is better > understood.
Sure. =) HTTP/2 has the following extra things that a user may want control over: - Preventing headers being added to the compression context. Good servers will automatically do this for things like Set-Cookie, but an application may have special knowledge about a header being security-relevant. There is no way to signal this in WSGI. - Forcing certain headers to be added to the compression context. The flip side of the first part is that an application may know that a header is likely to be repeatedly re-used, despite being something that would ordinarily vary, and it may want to pass this knowledge to the server. - Server push before the complete set of response headers are ready (i.e. before the original response body is rendered). - Long-running bi-directional communications channels, like Websockets. - Signaling information about client priority to the application so it can allocate resources effectively. - Signaling information about flow control to the application so it can allocate resources effectively. (Both of these two could *maybe* be done using generators with WSGI, but it would be imperfect.) - Controlling flow control windows for large responses (e.g. deliberately shrinking or widening them). - Controlling flow control widows for connections as a whole. - Graceful connection shutdown (emitting GOAWAY but continuing to process the outstanding requests/responses). - Efficient stream cancellation (e.g. sending RST_STREAM for unwanted/invalid requests without tearing down the connection, likely related to the previous point) HTTP/2 is a very featureful protocol which complex applications could really take advantage of. Worth remembering. >> Pushing via Link headers is not ideal because it delays the push until after >> the headers are ready to go, and there’s a tricky ordering concern here (RFC >> 7540 points out that any PUSH_PROMISE frames should be sent before the >> response headers and body are sent, which means that we temporarily block >> the response that is ready to go from WSGI. This is a minor concern, but >> worth noting.) >> >> However, I’m happy to say that Pushing via Link headers is the way to go if >> we’d rather not specify a WSGI-specific API for it. > > > It appears that Link could at least be a fallback. > > The idea of a separate callable to push resources in WSGI environ could still > be dealt with as an extension specification and so not need changes to the > WSGI specification itself. Worst case is all that callable does is add Link > headers to the response. This would likely have to be the case in Apache with > mod_h2 as wouldn’t expect handlers to have direct access to an API to do it > any other way, plus in mod_wsgi daemon mode is in the wrong process to access > any API. Yup, this is definitely an option.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
