The LP spec doesn't say "the LP request is not a JSON RPC request" explicitly. If it did, then, yes, I could get away with doing GET. Receiving a JSON RPC response is questionable at best in the case that this is true (although normal JSON over HTTP obviously is GETtable).
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
Agreed, this would be questionable at best. The JSON-RPC spec clearly states "A response may only be sent in reply to a request." Just to see what happens, I modified the miner to actually use GET without a request body on the LP connection. The response from pushpool is still a JSON-RPC response, just as if it had received the request:
GET /LP HTTP/1.1
Authorization: Basic a2FvX2dwdTpmUjMzbDAwN3I=
Accept-Encoding: gzip,deflate
Content-Type: application/json
Cache-Control: no-cache
User-Agent: Java/1.6.0_26
Host: pit.x8s.de:8337
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.1 200 ok
Content-Type: application/json
X-Roll-NTime: Y
Date: Mon, 11 Jul 2011 11:54:01 GMT
Content-Length: 591
{"id":1,"error":null,"result":{"midstate":"d3eed22cc5909d76ac118412da850d8dfabc49687f1674fbcc73cecc45166cbd","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"00000001faca27b55e2524d24df3ab7ef9392b5c85a11bb006de813b000001d00000000035940bd70e45c1e87c69af951db0705d893945dda73c0202ad691730070e15044e1ae4571a0abbcf00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
Bottom line: It seems that pools really don't care one way or another. So let's stick with proper JSON-RPC.