Re: Collating follow-up on the future of WSGI

--===============8098858969564417600==
Content-Type: multipart/signed; boundary="Apple-Mail=_9E6DFE00-B902-4DCF-BBC4-C76548214E7B"; protocol="application/pgp-signature"; micalg=pgp-sha256


--Apple-Mail=_9E6DFE00-B902-4DCF-BBC4-C76548214E7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 20 Jan 2016, at 06:04, Graham Dumpleton =
<[email protected]> wrote:
>=20
> For response content, if a WSGI application currently doesn=E2=80=99t =
set a Content-Length on response, A HTTP/1.1 web server is at liberty to =
chunk the response.
>=20
> So I am not sure what is missing.

My specific concern is the distinction between =E2=80=9Cat liberty to=E2=80=
=9D and =E2=80=9Crequired to=E2=80=9D. Certain behaviours that make =
sense with chunked transfer encoding do not make sense without it: for =
example, streaming API endpoints that return events as they arrive. =
Sending this kind of response with a HTTP/1.0-style content-length =
absent response (framed by connection termination) is utterly confusing, =
especially as some APIs consider the chunk framing to be semantic.

This can and does bite people, because while all major production WSGI =
servers use chunked transfer encoding in this situation, not all WSGI =
implementations do: in fact, wsgiref does not. This means that if an =
application has a production design requirement to use chunked transfer =
encoding in its responses it cannot rely on the server actually =
providing it.

I see two solutions to this problem: we could mandate that HTTP/1.1 =
responses that have no content length must be chunked, rather than =
falling back to HTTP/1.0 style connection-termination-framed responses, =
or we could have servers stuff something in the environ dictionary that =
can be checked by applications. Or, I suppose, we can conclude that this =
problem is not large enough, and that it=E2=80=99s =E2=80=9Ccaveat =
developer=E2=80=9D.

That, however, was my concern regard chunked responses.

Cory

--Apple-Mail=_9E6DFE00-B902-4DCF-BBC4-C76548214E7B
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-----

iQIcBAEBCAAGBQJWn2cNAAoJEHD+F/imQ+FbXAQP/jRxRC3s6tL1lMw4Lum1Jwxe
i2vUiIy1aknP16v4K767owtFkn2En8nGuosw5yh/Yb8AaKJCk3dmj3gg9vLB/fxn
BPHHCvanGrXRJOo72zU2rYSAla7aU5ximdcxVGcdmCiZXu0ui7EJ5sjW6MLeJDq5
+CUyguQogOrZGSN8LXPsOmWkE6SSw9N59tKeDvY2Ry37hWDcgpIXcToFrv7zBl+G
kRz9UBXNGtg2T0l3zpdGVtvHoOzEk7OVn6CvAHRmFpwCpl7hhMlq0S1wk5+v21A7
coSLEgKziY6qtVuccyx6Q2Ksf+v2EOo+DHCmkDr6YOsZUtlBGz9affTgzExoh9oY
rPKouNxDHm0/RxG3G9D78CsteORbI9S8ger9TSuKqxyduOWfGMDmGHDxACN5AccY
TBkxH7so060hE124H7w1SZ0braA4n0JQIK6QiTNxPgQHsi3e+UN7KN+ZPYRlaEoc
9W7SScZUiacOzIK6BQOog4LhtBd1vYmzV6tPfm3by33AUqnWavZLMuTCVEqUlCOi
eX+EIFScTBu0nHxTJ2CzQDO7VNlBjkpCAqkhifYv/ESlmhz12/47J9zZtKNe9TX5
iiWdkOoFc6swm9bfMAAGnLEmv6p5JsB3RZfd/g14b/sOc7AuyL0/8Mnhy3/6BQK+
6XqAh9hZ040qb1TQrMEY
=eQvI
-----END PGP SIGNATURE-----

--Apple-Mail=_9E6DFE00-B902-4DCF-BBC4-C76548214E7B--

--===============8098858969564417600==
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

--===============8098858969564417600==--