From: annevankeste...@gmail.com [mailto:annevankeste...@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.)

Reply via email to