Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.5.1

Bug #15785 HTTP_Request2 fails for servers sending HTTP-StatusCode 100 Continue (curl-ada)
Submitted: 2009-01-27 16:43 UTC
From: kase Assigned: avb
Status: Closed Package: HTTP_Request2 (version CVS)
PHP Version: 5.2.8 OS:
Roadmaps: 0.3.0    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 5 + 45 = ?

 [2009-01-27 16:43 UTC] kase (Timo Gmell)
Description: ------------ Hi, after much testing, there are still some requests that fail with the new HTTP_Request2 package. One problem is the "100 Continue" header, that is sent by some servers if request-method is post and http-version is 1.1. You can force this behavior by sending a client header "Expect" => "100-continue" to a http 1.1 server, but the server could send this header without the Expect client header too. (see: The "receivedHeaders" event is fired twice, if the server sends a 100 continue, but i think, this bug is fixed if 100 continue is handled correctly. The socket adapter works perfectly, this special status code (+101 too) is implemented in Socket.php line 381. Thanks! PS: You can use the provided url (in test script) for testing. PPS: Response of a 100 continue request: HTTP/1.1 100 Continue\r\n \r\n HTTP/1.1 200 OK\r\n Headers... Body... Test script: --------------- // Curl $url = new Net_URL2(''); $request = new HTTP_Request2($url, HTTP_Request2::METHOD_POST); $request->setAdapter('Curl'); $request->setConfig('protocol_version', '1.1'); $request->setHeader('Expect', '100-continue'); $request->addPostParameter('a', 'b'); $response = $request->send(); var_dump($response->getStatus() == 200 ? 'ok' : 'err'); // var_dump($response); // Socket $url = new Net_URL2(''); $request = new HTTP_Request2($url, HTTP_Request2::METHOD_POST); $request->setAdapter('Socket'); $request->setConfig('protocol_version', '1.1'); $request->setHeader('Expect', '100-continue'); $request->addPostParameter('a', 'b'); $response = $request->send(); var_dump($response->getStatus() == 200 ? 'ok' : 'err'); // var_dump($response); Expected result: ---------------- string(2) "ok" string(2) "ok" Actual result: -------------- string(3) "err" string(2) "ok"


 [2009-01-27 17:15 UTC] avb (Alexey Borzov)
Are you sure you are using the current CVS version? I've seen a similar problem in Curl adapter a couple of days ago when working on Digest authentication and fixed that. Cannot reproduce here with current CVS.
 [2009-01-28 08:36 UTC] kase (Timo Gmell)
Hi, i have checked this with 0.2.0 and CVS from Jan 23. and you fixed it in CVS from Jan 24. :) I have updated to the latest CVS now and it seems to work. The events sentHeaders and receivedHeaders are called twice, is this expected behavior? The receivedHeaders event should be ok, because we receive 2 headers, one with status code 100 (+newline) and a second, the "real" header (+newline). But the sentHeaders event is questionable, the client headers are splitted to the first HTTP-GET/POST URL line and the rest of the client headers, after the 100 continue is received (i think, i have not checked this). Thanks! sentHeaders receivedHeaders sentHeaders receivedHeaders receivedBodyPart receivedBodyPart receivedBody
 [2009-01-28 15:18 UTC] avb (Alexey Borzov)
Yeah, I see now that my fix was incomplete. Sending 2 sentHeaders events with the *same* headers doesn't look right, this is different from the digest auth where there actually are 2 requests performed. Also Socket adapter doesn't bother with receivedHeaders events for 100 and 101 responses, we should either send this event in both adapters or in none of them.
 [2009-01-28 21:16 UTC] avb (Alexey Borzov)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.