php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #9280 HTTP/1.1 Expect: header not honoured
Submitted: 2001-02-15 09:10 UTC Modified: 2002-08-14 13:16 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: paulc at datatote dot co dot uk Assigned:
Status: Closed Package: Apache related
PHP Version: 4.0.4pl1 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
 [2001-02-15 09:10 UTC] paulc at datatote dot co dot uk 
When a PHP page is requested via HTTP/1.1, and the HTTP
header "Expect: 100-continue" is supplied, PHP does not
honour the request.  This is because it is failing
to call ap_should_client_block().

The file sapi/apache/mod_php4.c needs modification. The
following change has been tested and works. Hopefully
someone can make sense of this diff output:

--- sapi/apache/mod_php4.c   Wed Jan  3 22:07:59 2001
+++ sapi/apache_modified/mod_php4.c  Thu Feb 15 13:56:12 2001
@@ -159,14 +159,16 @@
        void (*handler)(int);

        handler = signal(SIGPIPE, SIG_IGN);
-       while (total_read_bytes<count_bytes) {
-               hard_timeout("Read POST information", r); /* start timeout timer
-               read_bytes = get_client_block(r, buffer+total_read_bytes, count_bytes-total_read_bytes);
-               reset_timeout(r);
-               if (read_bytes<=0) {
-                       break;
+       if (ap_should_client_block(r)) {
+               while (total_read_bytes<count_bytes) {
+                       hard_timeout("Read POST information", r); /* start timeout timer */
+                       read_bytes = get_client_block(r, buffer+total_read_bytes, count_bytes-total_read_bytes);
+                       reset_timeout(r);
+                       if (read_bytes<=0) {
+                               break;
+                       }
+                       total_read_bytes += read_bytes;
                }
-               total_read_bytes += read_bytes;
        }
        signal(SIGPIPE, handler);
        return total_read_bytes;

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-06-14 20:45 UTC] sniper@php.net 
Do you have any example script that can be used to reproduce
this behaviour? (I'm being lazy here.. :)
 [2001-07-22 12:49 UTC] andy@php.net 
no feedback after 38 days.
 [2001-07-23 09:17 UTC] andy@php.net 
paulc@datatote.co.uk emailed me with his response.  I am
re-opening this bug.  This is what he said...
-------------------------------------------------------

First I created a simple PHP script which does nothing.  I've
called it "null.php" and it's in the root of my servers.  It
contains simply:

<BODY> hello
</BODY>  Now to test, I telnet to the web server port.
First I connect to
the machine with a stock PHP (4.0.4pl1) on it, and paste in the
following:

POST /null.php HTTP/1.1
Host: yellow.datatote.co.uk
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
Accept: */*
Expect: 100-continue

Now I add an extra blank line after the Expect: header.  Nothing
happens.

Next I connect to the machine with my modified PHP on it, and
paste in:

POST /null.php HTTP/1.1
Host: etweb_qa.datatote.co.uk
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
Accept: */*
Expect: 100-continue

Now I add an extra blank line after the Expect: header.  The
web server responds with:

HTTP/1.1 100 Continue

This is as per the HTTP 1.1 spec (RFC 2068, section 8.2).

To check that this behaviour is definitely PHP related, I
created
a dummy perl script (similar to the PHP one above) and return to
the http port of the original machine (with unmodified PHP) and
paste in:

POST /cgi-bin/null.pl HTTP/1.1
Host: yellow.datatote.co.uk
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
Accept: */*
Expect: 100-continue

Adding an extra blank line after the Expect: produces the
correct
"HTTP/1.1 100 Continue" line.

This may not be quite what you wanted, but it should give you
all the information you need to see the fault and to see
that the
fix works.

Note that the two servers mentioned above are not publically
accessible (sorry - development machines).  I can provide public
access to a null.php on a box with my patched PHP if that is any
help.

Also,  we originally spotted this bug because someone was trying
to use a standard URL fetch method using JRE 1.3 (I'm not a Java
programmer so I don't know offhand what the method was).
 [2002-08-14 13:16 UTC] iliaa@php.net 
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation 
problem, the fix will show up soon at http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites.
Thank you for the report, and for helping us make PHP better.
 [2003-06-25 13:20 UTC] tgagne at wideopenwest dot com 
Though this bug was reported in 2001, it still doesn't appear to have been addressed in 4.2.2's mod_php4.c file.

It is also a problem with apache2, though I don't know what role mod_php4 plays there if any.  Using "curl" to POST a file to a PHP script results in all kinds of errors because Apache2 never responds with a "100 Continue".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon May 05 23:01:28 2025 UTC