buger/goreplay

Some 100 Continue responses not correctly handled, resulting in lost POST/PUT requests

bruce34 opened this issue · 1 comments

As commented on issue 1028, we are seeing that on upgrading from 1.0.0rc2 to 1.3.3 we are losing POST traffic that contains a client header of:
Expect: 100-continue
and a server response of:
HTTP/1.1 100 (note the space after 100)

The code here assumes the response from the server will be exactly 25 bytes long (i.e. HTTP/1.1 100 Continue) but any reason phrase, and hence different lengths, should be allowed.

I could perhaps have a shot at generating a pull request to fix this, but I will need help as to where to add this to the code - currently the p.Ack addition is done without knowledge of what the server responded with.

Same here, even though Jetty responds with HTTP/1.1 100 Continue; most of our clients use a 100-continue expectation for SOAP requests, but gor (v1.3.3 ) would only capture the small fraction of requests that do not use it.