Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Wed, 20 Jan 2016 07:24:58 +1000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============7658764111100105489== Content-Type: multipart/alternative; boundary="Apple-Mail=_FACF5BF1-F56C-4F4A-99E5-4469BD5DB6D8" --Apple-Mail=_FACF5BF1-F56C-4F4A-99E5-4469BD5DB6D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jan 2016, at 2:55 AM, Cory Benfield <[email protected]> wrote: >=20 > Content Lengths > ~~~~~~~~~~~~~~~ >=20 > We should clarify in the new specification that an application that = reads beyond the logical length of the request as given by = CONTENT_LENGTH will have its reads return immediately with the empty = string. Servers are required to police that logic. This is codifying = existing practice, and would also make CONTENT_LENGTH purely advisory. Clarification on this point as maybe I didn=E2=80=99t explain well = enough what I was suggesting. It isn=E2=80=99t that want an empty string to be returned immediately if = an attempt is made to read more than CONTENT_LENGTH, but that it is = permissible that a WSGI server CAN actually return more than what = CONTENT_LENGTH states. This would occur for example with chunked request content where = CONTENT_LENGTH would actually be 0 (not present). Or, with compressed = request content which is decompressed by the underlying web server. Thus = the actual amount of data available to read would be greater in length = than the original non zero CONTENT_LENGTH. A WSGI application wishing to support these situations would, instead of = reading up to CONTENT_LENGTH, would read in data until it is returned an = empty string, indicating end of input. The complication comes in that PEP 333 simply said you can=E2=80=99t = read more than CONTENT_LENGTH. It didn=E2=80=99t really provide a = guarantee that if you did you got an empty string back. In PEP 3333, a guarantee was added that when you had read all input you = would get an empty string. There was no version change for WSGI in PEP = 3333, ie., wsgi.version, so you don=E2=80=99t really have a proper way = of knowing for sure that a WSGI server will work that way so WSGI = applications still tend to be written to only read up to CONTENT_LENGTH. An updated WSGI 1.1, so wsgi.version would be updated, would provide a = means of being able to know if empty string is guaranteed, but also the = additional new change that you can read past CONTENT_LENGTH and still = get data, with input eventually terminated by empty string. I have at least one blog post about this some where so I will try and = find it. Travelling this morning though so no more time to try and find = it right now. Graham= --Apple-Mail=_FACF5BF1-F56C-4F4A-99E5-4469BD5DB6D8 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 2:55 AM, Cory Benfield <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div 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"">Content Lengths</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"">~~~~~~~~~~~~~~~</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""><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"">We should clarify in the new = specification that an application that reads beyond the logical length = of the request as given by CONTENT_LENGTH will have its reads return = immediately with the empty string. Servers are required to police that = logic. This is codifying existing practice, and would also make = CONTENT_LENGTH purely advisory.</span></div></blockquote></div><br = class=3D""><div class=3D"">Clarification on this point as maybe I = didn=E2=80=99t explain well enough what I was suggesting.</div><div = class=3D""><br class=3D""></div><div class=3D"">It isn=E2=80=99t that = want an empty string to be returned immediately if an attempt is made to = read more than CONTENT_LENGTH, but that it is permissible that a WSGI = server CAN actually return more than what CONTENT_LENGTH = states.</div><div class=3D""><br class=3D""></div><div class=3D"">This = would occur for example with chunked request content where = CONTENT_LENGTH would actually be 0 (not present). Or, with compressed = request content which is decompressed by the underlying web server. Thus = the actual amount of data available to read would be greater in length = than the original non zero CONTENT_LENGTH.</div><div class=3D""><br = class=3D""></div><div class=3D"">A WSGI application wishing to support = these situations would, instead of reading up to CONTENT_LENGTH, would = read in data until it is returned an empty string, indicating end of = input.</div><div class=3D""><br class=3D""></div><div class=3D"">The = complication comes in that PEP 333 simply said you can=E2=80=99t read = more than CONTENT_LENGTH. It didn=E2=80=99t really provide a guarantee = that if you did you got an empty string back.</div><div class=3D""><br = class=3D""></div><div class=3D"">In PEP 3333, a guarantee was added that = when you had read all input you would get an empty string. There was no = version change for WSGI in PEP 3333, ie., wsgi.version, so you don=E2=80=99= t really have a proper way of knowing for sure that a WSGI server will = work that way so WSGI applications still tend to be written to only read = up to CONTENT_LENGTH.</div><div class=3D""><br class=3D""></div><div = class=3D"">An updated WSGI 1.1, so wsgi.version would be updated, would = provide a means of being able to know if empty string is guaranteed, but = also the additional new change that you can read past CONTENT_LENGTH and = still get data, with input eventually terminated by empty = string.</div><div class=3D""><br class=3D""></div><div class=3D"">I have = at least one blog post about this some where so I will try and find it. = Travelling this morning though so no more time to try and find it right = now.</div><div class=3D""><br class=3D""></div><div = class=3D"">Graham</div></body></html>= --Apple-Mail=_FACF5BF1-F56C-4F4A-99E5-4469BD5DB6D8-- --===============7658764111100105489== 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 --===============7658764111100105489==--