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
Write after end when piping #50
Comments
Thanks for reporting. If you don't find the time for a reduced test case, you can also send me your current code in private. |
Closing this because of inactivity. |
Using the follow-redirects 1.0.0 causes this reported write after end issue: follow-redirects/follow-redirects#50. It looks like the problem with follow-redirects was fixed in 1.1.0 follow-redirects/follow-redirects@9eec6f0 but if axios is going to update the dependency it might as well update to the latest version now.
Hello @RubenVerborgh , we have reproduced the issue with follow-redirects@1.2.3, HERE is the code. nodejs 6.8 Thanks for your contributions to OS! |
Thanks, will have a look. |
Thanks for making this reproducible @fogine - I'm sorry I never got around to doing so. |
UPDATE: I created a test that reproduces this issue here: https://travis-ci.org/binded/follow-redirects-test Hey @RubenVerborgh , I also stumbled upon this bug through axios: axios/axios#964 Full test case (indirectly, using axios :/): const test = require('blue-tape')
const axios = require('axios')
const express = require('express')
const { promisify } = require('util')
const concat = require('concat-stream')
const FormData = require('form-data')
const axiosVersion = require('axios/package.json').version
const listen = (app) => new Promise((resolve, reject) => {
const server = app.listen((err) => {
if (err) return reject(err)
resolve(server)
})
})
let closeServer
let baseURL
let port
let client
let server
const startServer = async () => {
const app = express()
app.post('/upload', (req, res) => {
// console.error(req.headers)
req.pipe(concat(() => {
res.json({ headers: req.headers })
}))
})
server = await listen(app)
closeServer = promisify(server.close.bind(server))
port = server.address().port
baseURL = `http://localhost:${port}`
client = axios.create({
baseURL,
/*
headers: {
'x-identity-token': 'test123',
},
*/
})
return server
}
test('start server', startServer)
test('upload file', async (t) => {
const buf = new Buffer('deadbeef', 'hex')
const form = new FormData()
form.append('some-image', buf, {
filename: 'some-image.jpg',
contentType: 'image/jpeg',
})
const headers = form.getHeaders()
const boundaryId = headers['content-type'].substr(-24)
t.deepEqual(headers, {
/* eslint-disable max-len */
'content-type': `multipart/form-data; boundary=--------------------------${boundaryId}`,
})
const response = await client.post('/upload', form, { headers })
t.deepEqual(response.data, {
headers: {
accept: 'application/json, text/plain, */*',
connection: 'close',
'content-type': `multipart/form-data; boundary=--------------------------${boundaryId}`,
host: `localhost:${port}`,
'transfer-encoding': 'chunked',
'user-agent': `axios/${axiosVersion}`,
},
})
})
test('stop server', async () => {
await closeServer()
}) The bug was introduced by follow-redirects@0.3.0 v0.2.0...v0.3.0 |
Thanks. I will create a fix soon. |
This fixes @olalonde's test case. Please verify. |
@RubenVerborgh thanks! |
@rwpino Thanks, replied there. |
Using the follow-redirects 1.0.0 causes this reported write after end issue: follow-redirects/follow-redirects#50. It looks like the problem with follow-redirects was fixed in 1.1.0 follow-redirects/follow-redirects@9eec6f0 but if axios is going to update the dependency it might as well update to the latest version now.
Using the follow-redirects 1.0.0 causes this reported write after end issue: follow-redirects/follow-redirects#50. It looks like the problem with follow-redirects was fixed in 1.1.0 follow-redirects/follow-redirects@9eec6f0 but if axios is going to update the dependency it might as well update to the latest version now.
I have a fairly simple case where I'm building a tarball-stream on the fly and piping it to a request that's going through
follow-redirects
.It almost immediately crashes with this error:
I'll see if I can find time to write a reduced test case at some point, but don't have time right at this moment. Switching to regular HTTP/HTTPS for this request fixes the problem.
The text was updated successfully, but these errors were encountered: