Tim Post

To narrow it down a bit more, any string over 20k seems to be doing this.

Here is a [gist](https://gist.github.com/3782081) with a test case. Once I hit past ~16k, `_single_line_reply()` (or rather, `fgets()`) starts truncating the result, and I can't figure out why. Note in the...

What version of PHP did you run that under? I'm using 5.4.5, about to try it on 5.3

Well, this is definitely not a bug in the library. I'm going to (tomorrow) rule out using the loopback device (127.0.0.1) and bind a few new servers to a public...

No, it's the same over all interfaces. I'm out of ideas here. I have tried every possible way of reading from a descriptor opened with `fsockopen()`. `fgets()` truncates, `fread()` blocks...

I played around with `stream_set_chunk_size()` and `stream_set_read_buffer()`. Tweaking these, I was able to get (reliably) up to 40kb read before that quirk kicked in. My `_single_line_reply()` function now looks like...

Well, that kludge did not work out so well. I'm going to add a sockets version of the library to my fork and get it working, then send a pull...

O.k., `socket_import_stream()` is probably not going to work for us, because we have to read from the socket prior to importing it, which causes it to error due to losing...

I solved the blocking issue. Actually, I have it just about working. A normal socket read in PHP uses the flag `PHP_BINARY_READ`, which takes its cues on where to stop...

It's .. still breaking at around 16k randomly. I was close to happy, I ran tests (repeating 100x each) half a dozen times, and then I get: > Failed asserting...