2017-01-04 2 views
0

die folgenden HTTP-Anfrage liefert eine 400 ERR_INVALID_REQ -- 400 auf POST-Anforderung

POST http://distservp1.pb.com/dstproduct.asp HTTP/1.1 
Proxy-Authorization: Basic Og== 
Host: distservp1.pb.com 
Connection: close 
Content-type: application/x-www-form-urlencoded 
Content-length: 638 

PBXML=%3CSignonReq%3E%0D%0A%0... 

die Antwort (Körper enthält keine weiteren Informationen) -

HTTP/1.0 400 Bad Request 
Server: squid/2.7.STABLE8 
Date: Wed, 04 Jan 2017 09:07:16 GMT 
Content-Type: text/html 
Content-Length: 2054 
X-Squid-Error: ERR_INVALID_REQ 0 
X-Cache: MISS from [ProxyName].local 
X-Cache-Lookup: NONE from [ProxyName].local:8080 
Via: 1.0 [ProxyName].local:8080 (squid/2.7.STABLE8) 
Connection: close 

Betrachten eines Pakets erfassen, den Körper von Die POST-Anforderung wird in zwei PDUs gesendet. Die 400 wird zurückgeschickt, bevor die zweite PDU gesendet wird - also würde ich mir vorstellen, dass der Fehler in den Headern liegt. Der Tintenfisch cache.log gerade zeigt -

clientTryParseRequest: FD 20 (192.168.120.72:49503) Invalid Request 

Eine ähnliche Anfrage von der DHC-Plugin in Chrom erzeugt gelingt -

POST http://distservp1.pb.com/dstproduct.asp HTTP/1.1 
Host: distservp1.pb.com 
Proxy-Connection: keep-alive 
Content-Length: 638 
Origin: chrome-extension://aejoelaoggembcahagimdiliamlcdmfm 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 
Content-Type: application/x-www-form-urlencoded 
Accept: */* 
Accept-Encoding: gzip, deflate 
Accept-Language: en-US,en;q=0.8 

Kann jemand sehen, was hier falsch läuft? Und irgendwelche Ideen, wie man es repariert? Wir können die Anwendung, die die Anfrage sendet, nicht ändern. Es funktioniert gut auf einem Gerät, das nicht über den Proxy weitergeleitet wird.

Antwort

0

Stellt sich heraus, die Anwendung in Frage ist ein Leerzeichen am Ende der Anforderungszeile hinzufügen. Dies veranlasst Squid, es abzulehnen.

Verwandte Themen