- From: Domenic Denicola <d@domenic.me>
- Date: Tue, 18 Nov 2014 09:34:14 +0000
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Takeshi Yoshino <tyoshino@google.com>, Rui Prior <rprior@dcc.fc.up.pt>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On Behalf Of Anne van Kesteren
> The only way I could imagine us doing this is by setting the Content-Length header value through an option (not through Headers) and by having the browser enforce the specified length somehow. It's not entirely clear how a browser would go about that. Too many bytes could be addressed through a transform stream I suppose, too few bytes... I guess that would just leave the connection hanging. Not sure if that is particularly problematic.
I don't understand why the browser couldn't special-case the handling of `this.headers.get("Content-Length")`? I.e. why would a separate option be required? So for example the browser could stop sending any bytes past the number specified by reading the Content-Length header value. And if you prematurely close the request body stream before sending the specified number of bytes then the server just has to deal with it, as they normally do...
I still think we should just allow the developer full control over the Content-Length header if they've taken full control over the contents of the request body (by writing to its stream asynchronously and piecemeal). It gives no more power than using CURL. (Except the usual issues of ambient/cookie authority, but those seem orthogonal to Content-Length mismatch.)
Received on Tuesday, 18 November 2014 09:34:44 UTC