2010-12-09 11 views
1

Ich muss den letzten Zeilenvorschub von einer http-Webanfrage entfernen, um mit einem json-rpc-Dienst zu kommunizieren. Die Anfrage, die .net erzeugt, sieht so aus.Entfernen eines Zeilenvorschubs aus der Kopfzeile einer C# -Web-Anforderung

POST http://localhost.:8332/ HTTP/1.1 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.1) 
Authorization: Basic dGlwa2c6dGlwa2c= 
Host: localhost.:8332 
Content-Length: 42 
Expect: 100-continue 
Connection: Keep-Alive 

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

Was würde ich dies wäre müssen (man beachte den fehlenden Zeilenvorschub nach dem letzten Header-Wert und der Beginn des json-Gehalts):

POST http://localhost.:8332/ HTTP/1.1 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.1) 
Authorization: Basic dGlwa2c6dGlwa2c= 
Host: localhost.:8332 
Content-Length: 42 
Expect: 100-continue 
Connection: Keep-Alive 
{"id":1,"method":"getinfo","params":[]} 

Ich kann nichts finden, wo ich manipulieren könnte der Header, der tatsächlich an den Service gesendet wird.

Siehe http://www.bitcoin.org/smf/index.php?topic=2170.0 für mehr Hintergrundinformationen über das Problem ...

+2

Wenn der Dienst die Anforderung wie Ihr zweites Beispiel benötigt, ist es kein gültiges HTTP. HTTP erfordert eine leere Zeile, die die Header vom Hauptteil trennt (falls vorhanden). –

+0

Haben Sie das getestet und sichergestellt, dass es ohne die Zeilenschaltung funktioniert? Um dies zu testen, können Sie Telnet verwenden (Telnet Host-Name 80, dann in Ihrer Anfrage aus einem Texteditor). Ich habe noch nie von einem Webserver gehört, der sich um \ r \ n oder \ n gekümmert hat. Hoffentlich macht das keinen Unterschied. Wenn dies der Fall ist, können Sie die NetworkStream-Klasse verwenden, um genau darüber nachzudenken, welche Zeichen Sie senden. –

+0

Auch Ihre HTTP-Anfrage sieht ungültig aus, weil sie nur einen Pfad nach dem POST-Verb anstelle einer vollständigen URL haben sollte (d. H./Anstelle von http://localhost.:8332/). Aber vielleicht ist das nur Geiger. –

Antwort

1

schließlich aufgelöst mein (Kern) Thema. Das Problem mit meiner Kommunikation mit dem RPC-Dienst war, dass ich keinen Inhaltstyp festgelegt hatte. Der Dienst benötigte einen Inhaltstyp "application/json-rpc", um ordnungsgemäß zu funktionieren.

+0

Froh, dass du es herausgefunden hast. Es klang wie ein wirklich komischer und frustrierender Bug. –

Verwandte Themen