Bitp.it Pool Not Working

[Obsi]

Not sure what the issue here is, if someone can point me in the direction to debug this I'll happily do it. The pool works fine with a direct connection from phoenix, but doesn't get used at all via proxy.

I've double checked pool info in the proxy DB and it is correct. Perhaps related to the multipool issue?

[Obsi]

Ok, I did a tcpdump between a working phoenix connection to bitp.it and a failing one from the proxy. These are the getwork requests:
Phoenix-
POST / HTTP/1.1
Content-Length: 44
Host: bitp.it:8334
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/r100

{"params": [], "method": "getwork", "id": 1}

Bitcoin-Mining-Proxy:
Host: pool.bitp.it:8334
Content-Length: 44
Content-Type: application/json-rpc
Authorization: Basic xxx

{"params":[],"method":"getwork","id":"json"}

---

I'm gonna take a wild guess and say their server is looking for "POST / HTTP/1.1" or the User-Agent header. Time to dig into the proxy code and see what I can find.

[Obsi]

Well, I futzed with the code for a bit, but I can't seem to get it to output the POST header before the others without rewriting the stream_create_context code into curl or something. The user agent string doesn't seem to be an issue. Looking into the issue more, it seems to be a problem with nginx returning 502 Bad Gateway errors when this header isn't set.

[jwhitehorn]

I'm with bit pit, and we actually looked at this issue. It's kinda a bug in PHP that makes a bug in Node (which our pools is built on) upset.

The details of the Node bug are here: nodejs/node-v0.x-archive#1165

But in the bug you can see references to the PHP bug. Apparently when PHP sends an HTTP request it appends two sets of CRLF, despite the HTTP spec saying to do a single CRLF. Moreover, Node is a stickler for the specs and fails miserable at even parsing this malformed incoming HTTP request.

We (at bit pit) are kinda in a tough spot. Since Node is our stack, and since our stack is refusing to parse the HTTP request, we can't really do anything with the request until Node fixes their bug.

However, if there is anyway at all that the mining proxy could issue requests that have a single trailing CRLF, then it would fix things. I'm not sure if this is even an option for you.

[cdhowie]

@jwhitehorn: Thanks for digging into this. I'm going to experiment with the new backends I've been working on; hopefully I can get them to issue the request correctly (if they don't already).

As much as I'd like to fix this issue in the PHP backend too, I'm not about to roll my own HTTP client library to work around this.