Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Wed, 20 Jan 2016 16:04:48 +1000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============8139502909393435997== Content-Type: multipart/alternative; boundary="Apple-Mail=_874A48DA-8D04-430B-AF5F-93BC44585FF5" --Apple-Mail=_874A48DA-8D04-430B-AF5F-93BC44585FF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jan 2016, at 8:56 AM, Robert Collins <[email protected]> = wrote: >=20 >>=20 >> Chunked Transfer Encoding >> ~~~~~~~~~~~~~~~~~~~~~~~~~ >>=20 >> It would be nice to formalise chunked transfer encoding in WSGI. = Currently there is no way to signal to applications that chunked = transfer encoding is in use by the client, or for the application to = request it from the server. >>=20 >> This seemed to be a low priority work item, but if we can make this = enhancement easily then it's worth considering. >=20 > I'm very much against this. I think its an abstraction violation. It > makes as much sense as exposing the guts of HTTP/2 framing to an > application. A way of doing Trailers would make sense. I would agree in as much that what is stated here is confusing. There are two concerns. Chunked request content, and use of chunking on = response content. For chunked request content it can=E2=80=99t currently be done by PEP = 3333. This is what the separate issue about reading more than = CONTENT_LENGTH is about. For chunked request content, a WSGI application = would never see raw chunked stream as it would be de-chunked by the web = server. 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. So I am not sure what is missing. BTW, this reminds me of another area of the WSGI PEP which is broken = which I have talked about before in: = http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html = <http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html= > There might be another post about it. Basically the PEP is wrong is saying a WSGI server is allowed to = construct a Content-Length header where it identifies the response as a = list containing one string. Doing so can break the supposed equivalence = in headers between GET and HEAD. So another issue that would be cleaned up in any 1.1 final version of = the specification. Graham= --Apple-Mail=_874A48DA-8D04-430B-AF5F-93BC44585FF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 20 Jan 2016, at 8:56 AM, Robert Collins <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><blockquote = type=3D"cite" style=3D"font-family: Helvetica; font-size: 16px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = class=3D"Apple-interchange-newline">Chunked Transfer Encoding<br = class=3D"">~~~~~~~~~~~~~~~~~~~~~~~~~<br class=3D""><br class=3D"">It = would be nice to formalise chunked transfer encoding in WSGI. Currently = there is no way to signal to applications that chunked transfer encoding = is in use by the client, or for the application to request it from the = server.<br class=3D""><br class=3D"">This seemed to be a low priority = work item, but if we can make this enhancement easily then it's worth = considering.<br class=3D""></blockquote><br style=3D"font-family: = Helvetica; font-size: 16px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><span style=3D"font-family: Helvetica; font-size: 16px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">I'm very much against this. I think its = an abstraction violation. It</span><br style=3D"font-family: Helvetica; = font-size: 16px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 16px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">makes as much sense as exposing the guts of = HTTP/2 framing to an</span><br style=3D"font-family: Helvetica; = font-size: 16px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 16px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">application. A way of doing Trailers would make = sense.</span></div></blockquote></div><br class=3D""><div class=3D"">I = would agree in as much that what is stated here is confusing.</div><div = class=3D""><br class=3D""></div><div class=3D"">There are two concerns. = Chunked request content, and use of chunking on response = content.</div><div class=3D""><br class=3D""></div><div class=3D"">For = chunked request content it can=E2=80=99t currently be done by PEP 3333. = This is what the separate issue about reading more than CONTENT_LENGTH = is about. For chunked request content, a WSGI application would never = see raw chunked stream as it would be de-chunked by the web = server.</div><div class=3D""><br class=3D""></div><div class=3D"">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.</div><div class=3D""><br class=3D""></div><div class=3D"">So= I am not sure what is missing.</div><div class=3D""><br = class=3D""></div><div class=3D"">BTW, this reminds me of another area of = the WSGI PEP which is broken which I have talked about before = in:</div><div class=3D""><br class=3D""></div><div class=3D""> = <a = href=3D"http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-reques= ts.html" = class=3D"">http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-req= uests.html</a></div><div class=3D""><br class=3D""></div><div = class=3D"">There might be another post about it.</div><div class=3D""><br = class=3D""></div><div class=3D"">Basically the PEP is wrong is saying a = WSGI server is allowed to construct a Content-Length header where it = identifies the response as a list containing one string. Doing so can = break the supposed equivalence in headers between GET and = HEAD.</div><div class=3D""><br class=3D""></div><div class=3D"">So = another issue that would be cleaned up in any 1.1 final version of the = specification.</div><div class=3D""><br class=3D""></div><div = class=3D"">Graham</div></body></html>= --Apple-Mail=_874A48DA-8D04-430B-AF5F-93BC44585FF5-- --===============8139502909393435997== 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 --===============8139502909393435997==--