Issue with long params

[cergfix]

Hello,

Probably similar to this issue: https://code.google.com/p/fcgi4j/issues/detail?id=2
Happens when param values are quite long (query string in my case).

java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.writev0(Native Method)
at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51)
at sun.nio.ch.IOUtil.write(IOUtil.java:148)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524)
at java.nio.channels.SocketChannel.write(SocketChannel.java:493)
at com.googlecode.fcgi4j.FCGIConnection.writeStdin(FCGIConnection.java:406)
at com.googlecode.fcgi4j.FCGIConnection.write(FCGIConnection.java:367)

This happens when setting connection.setQueryString(queryString); or connection.addParams("REQUEST_URI", queryString);

Any idea? :)

[Nyholm]

Yes, I believe it is the same issue. I will try to debug it and write some proper test code.

[cergfix]

Was doing some debugging using strace on php5-fpm (comparing behavior to the following C client https://github.com/abhigna/fcgi-client). C client puts all the params into one big single request. Could this be the issue?

[pid 22051] read(3, "\1\1\0\1\0\10\0\0", 8) = 8
[pid 22051] read(3, "\0\1\0\0\0\0\0\0", 8) = 8
[pid 22051] read(3, "\1\4\0\1\3m\0\0", 8) = 8
[pid 22051] read(3, "\17\20SCRIPT_FILENAME/test/test.php\v\tSCRIPT_NAME/test.php\r\16DOCUMENT_ROOT/home/abhigna/\v\200\0\0\0REQUEST_URI/test/test.php?option=fwefwefew&cewcewcew=29735429297354292973542929735429297354292973542929735429297354292973542929735429297100\10\tPHP_SELF/test.php\4\5TERMlinux\4\0PATH\21\1PHP_FCGI_CHILDREN2\25\4PHP_FCGI_MAX_REQUESTS1000\t\tFCGI_ROLERESPONDER\17\17SERVER_SOFTWARElighttpd/1.4.29\v\fSERVER_NAMESimpleServer\21\7GATEWAY_INTERFACECGI/1.1\v\4SERVER_PORT9000\v\tSERVER_ADDR127.0.0.1\v\0REMOTE_PORT\v\tREMOTE_ADDR127.0.0.1\t\10PATH_INFOno value\f\10QUERY_STRINGno value\16\3REQUEST_METHODGET\17\3REDIRECT_STATUS200\17\10SERVER_PROTOCOLHTTP/1.1\t\16HTTP_HOSTlocalhost:9000\17\nHTTP_CONNECTIONkeep-alive\17gHTTP_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11\v?HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\24\16HTTP_ACCEPT_LANGUAGEen-US,en;q=0.8", 877) = 877
[pid 22051] read(3, "\1\4\0\1\0\0\0\0", 8) = 8
[pid 22051] time(NULL)                  = 1428712509
[pid 22051] lstat("/test/test.php", {st_mode=S_IFREG|0644, st_size=61, ...}) = 0
[pid 22051] lstat("/test", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
.........

[pid 22050] read(3, "\1\1\0\1\0\10\0\0", 8) = 8
[pid 22050] read(3, "\0\1\1\0\0\0\0\0", 8) = 8
[pid 22050] read(3, "\1\4\0\1\0\32\0\0", 8) = 8
[pid 22050] read(3, "\21\7HTTP_X_GEOIP_CITYTallinn", 26) = 26
[pid 22050] read(3, "\1\4\0\1\0&\0\0", 8) = 8
[pid 22050] read(3, "\26\16HTTP_X_GEOIP2_TIMEZONEEurope/Tallinn", 38) = 38
[pid 22050] read(3, "\1\4\0\1\0\31\0\0", 8) = 8
[pid 22050] read(3, "\17\10SERVER_PROTOCOLHTTP/1.1", 25) = 25
[pid 22050] read(3, "\1\4\0\1\0\35\0\0", 8) = 8
[pid 22050] read(3, "\22\tHTTP_CACHE_CONTROLmax-age=0", 29) = 29
[pid 22050] read(3, "\1\4\0\1\0!\0\0", 8) = 8
[pid 22050] read(3, "\26\tHTTP_X_GEOIP2_NETSPEEDCable/DSL", 33) = 33
[pid 22050] read(3, "\1\4\0\1\0\27\0\0", 8) = 8
[pid 22050] read(3, "\r\10DOCUMENT_ROOT/test/", 23) = 23
[pid 22050] read(3, "\1\4\0\1\0\31\0\0", 8) = 8
[pid 22050] read(3, "\v\fREMOTE_ADDR11.11.11.111", 25) = 25
[pid 22050] read(3, "\1\4\0\1\0\35\0\0", 8) = 8
[pid 22050] read(3, "\31\2HTTP_X_GEOIP_COUNTRY_CODEEE", 29) = 29
[pid 22050] read(3, "\1\4\0\1\0\220\0\0", 8) = 8
[pid 22050] read(3, "\v\0\0\0\200REQUEST_URI/test/test.php?option=fwefwefew&cewcewcew=29735429297354292973542929735429297354292973542929735429297354292973542929735429297100", 144) = 144
[pid 22050] close(3)                    = 0

[Nyholm]

Yeah, maybe so.
As you may know, I'm not the original author of this. I do not know how everything works by heart. Any more help debugging are appreciated.

[cergfix]

Possible fix (com/googlecode/fcgi4j/message/FCGIParams.java:65)

   private void bufferLength(ByteBuffer byteBuffer, String str) {
        int length = str.length();
        if (length < 0x80) {
            byteBuffer.put((byte) length);
        } else {
            byteBuffer.put((byte) 0x80);
            byteBuffer.put((byte) 0);
            byteBuffer.put((byte) 0);
            byteBuffer.put((byte) length);
        }
    }

Going to try to validate this.

[Nyholm]

You gave me an idea. The first bit in the first byte must be a 1. Try this PR (#2) and let me know if it works for you.

[cergfix]

Looks like this is solved now :)

[Nyholm]

Thats great!
Thank you for helping me debug this. =)