Re: WSGI 2.0 Round 2: requirements and call for interest

--===============7317237150098553959==
Content-Type: multipart/signed; boundary="Apple-Mail=_D30745FC-1AE3-4A97-8D5C-F0DFECC7058E"; protocol="application/pgp-signature"; micalg=pgp-sha256


--Apple-Mail=_D30745FC-1AE3-4A97-8D5C-F0DFECC7058E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 6 Jan 2016, at 20:06, Graham Dumpleton <[email protected]> =
wrote:
>=20
>=20
>> On 6 Jan 2016, at 10:19 PM, Cory Benfield <[email protected]> wrote:
>>=20
>>=20
>>> On 6 Jan 2016, at 09:48, Graham Dumpleton =
<[email protected]> wrote:
>>>=20
>>> If this does solve the push issue, what is there in HTTP/2 then that =
one couldn=E2=80=99t do via the existing WSGI interface?
>>=20
>> Well, plenty, but none that we=E2=80=99d *want* to expose via WSGI =
with the possible exception of long-running bi-directional =
communications channels like Websockets, which you=E2=80=99ve already =
expressed a desire to expose in a different API. =3D)
>=20
> Can you elaborate more on the =E2=80=98plenty=E2=80=99 part.
>=20
> 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. =3D)

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=E2=80=99s 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.)
>>=20
>> However, I=E2=80=99m happy to say that Pushing via Link headers is =
the way to go if we=E2=80=99d rather not specify a WSGI-specific API for =
it.
>=20
>=20
> It appears that Link could at least be a fallback.
>=20
> 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=E2=80=99t 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.


--Apple-Mail=_D30745FC-1AE3-4A97-8D5C-F0DFECC7058E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWjkTsAAoJEHD+F/imQ+Fb1T0P/2LWaABY0ZRylrwj2eVVBv7S
1fkfNGsvIpuQZGLa+SIYmc8pR46R0WasxME1+tAty9+mLB+vInit6WR4rmFuwtBa
mDKq7BLtsOy7NlrNeoAJkCLU799RvcklWYapQlMTWw/uJpttri2ogJxJeHDDc/qO
laANyJ14l3MC2Hv2+2oG02EOyzlM08NYsqqCDvp/SdkPl8tZ6JQBZH10DHxf0lkU
SzHwhdAMGQTtLLBeFUmUlVchUbjJyKZlhobGylOW+l8RT3Hy/89rdl0vMMReDwRe
MHhm4wwzvkLN1WJgOJdeJopgJ/5P6BfF8IPMTLTOy4NJsJLKJ8giSxLYyQDqzMss
rsUoNAQ/BQqrn7QxZP7VIpx3Nr4nkhYTSMDUoPQdPv0hhtFxmRajHDtcnBE23y9i
CPi2yYGd5sXHfg/ynwHCDwo+t4RSVlb1FHKedJR3I3K3jttXSjTqxBbKcwFxMFEW
fAdBP6kbZQecCEL3JQrFKkBytud3ix4DXPwfYJI52Gj+z+qKjjfegK4oPV9e4J+N
fgIl5fav3aRwimhjkiaEXtGphApxBN3yO9Ke+6XnN1PRc0jgk9tlS8uptj26E26/
jy79cMi6q74LMV3YnvAr1hlcHEEI6zAXD84lbmXPiP2xYTQs9q/0lGg0TlX2g452
i1de2bak5949vssaG11m
=kToX
-----END PGP SIGNATURE-----

--Apple-Mail=_D30745FC-1AE3-4A97-8D5C-F0DFECC7058E--

--===============7317237150098553959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

--===============7317237150098553959==--