-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unknown stream handling (content-length unknown) #90
Comments
Maybe something like this (more like an idea, tests are missing etc): derjust@c2804ff |
And in fact it's forbidden by the HTTP spec: it's either content-lenght or content-encoding, not both. See #70 where support for streams of unknown size is proposed. |
Another Related PR here #70 This will be pretty important for me. It would not be ideal making a dependency on a fork, opening up multiple connections or creating a protocol for this : / |
It will be solved in |
Hi everyone,
This is more a documentation/enhancement discussion than anything else:
My use case was to send a
ReadableStream
viamultipart/form-encoded
(more or less a form with just afile
input field) to a remote host. The remote side was 'fxied' and I can't do anything about it.Without the desire to create temporary files the challenge was to stream the input directly to the remote host.
This turned out to be way more complicated as the length of the input stream is unknown. Whereas with chunking it is absolutely fine to have no
content-length
.Request on it's own tries very hard to come up with a
content-length
whereas theFormData.getLength
calculates the wrong length (in fact counting the boundary string length only).With the
_lengthRetrievers
there is a nice approach to define the length for streams. And throwing in error causes Request.js to skip thecontent-length
altogether.with in turn also activates chunking which is working as expected.
But to get into this handling, the
value
must be specially crafted. As the value has to look like a file stream as there are two different validations: Fullfilling thisallows access for the lazy length determination.
Whereas the logic later on tests for this:
value.hasOwnProperty('fd')
Therefore with this kind of code:
Therefore wouldn't it make sense to have an additional
option
which provides cleaner access to "We don't known how long it is"?The text was updated successfully, but these errors were encountered: