I have no idea how to capture traffic on Linux, but I could do so if there
are some good instructions somewhere. The problem generally takes hundreds
of MB of traffic to reproduce, however, so I'm not sure if logging that
traffic will affect it and cause it to not occur, but I'm willing to try.
I did a git bisect and found the revision in the v0.8 history which
"caused" the issue, but unfortunately, I think that is a red herring, as
the revision is just one that fixed keep-alive being broken on that branch
[1], and older than that revision keep-alive is simply off, so the traffic
is drastically different (not to mention orders of magnitudes slower in my
test). On the 0.6 branch, however, even with keep-alive functioning
correctly, I do not see this problem, so that leads me to believe that
something broke while keep-alive was also broken on the 0.8 branch, which
makes it much harder to bisect. I may try cherry-picking in the keep-alive
fix while doing a bisect to see if I can narrow it down, though since each
test can take up to a half hour before it's conclusive, I'm not sure how
productive that will be.
[1]
https://github.com/Joyent/node/commit/a6f3451e2549d0b82ff18990e8bfe28...
On Friday, September 21, 2012 5:45:57 AM UTC-7, Ben Noordhuis wrote:
> On Fri, Sep 21, 2012 at 12:00 AM, Jimb Esser <wast...@gmail.com<javascript:>>
> wrote:
> > As a follow-up, it looks like the data I get back from the response
> often
> > has "\r\n2000\r\n" in the middle of what otherwise looks like good data,
> so
> > I'm guessing something is going wrong with processing multi-part
> (chunked?
> > whatever is the right term?) responses, and it sometimes reads too much
> and
> > then tries to read the next chunk size from the middle of the response
> data
> > (sometimes getting an "invalid chunk size" error, or if it gets lucky
> and
> > reads a small number, it just truncates my response (though leaves the
> > "\r\n2000\r\n" in the middle of it).
> Do you have some captured traffic I can look at?
