You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Jose Kahan <Jo...@inrialpes.fr> on 1999/01/27 00:04:07 UTC

Re: protocol/3575: 100-Continue isn't being sent anymore

On 22 Dec 1998 coar@apache.org wrote:

Hello,

Sorry for the delay in answering your answer to my bug report.
I have now analyzed and found where the bug. I'm enclosing a patch too.

YOUR LAST REPLY

> This is by design.  From the src/CHANGES file:
> 
>   *) Added a complete implementation of the Expect header field as
>      specified in rev-05 of HTTP/1.1.  Disabled the 100 Continue
>      response when we already know the final status, which is mighty
>      useful for PUT responses that result in 302 or 401. [Roy Fielding]
> 
> Thanks for the report, and for using Apache.

I agree with the above. However, Apache won't generate at all
any Expect:100-Continue when sending a PUT. You can test this
with your favorite PUT or POST scripts.

DESCRIPTION OF THE PROBLEM

Apache initiallty detects the Expect: 100-Continue header and sets up
an internal flag (expecting_100) in a request_rec variable (let's say r).
However, later on down the pipeline, there's a call  
http_request.c:internal_internal_redirect() where a new request_rec
variable is created (new_uri). Several fields of r are copied to new_uri,
however this is not the case of expecting_100.

Later on, there's a call to
http_protocol.c:ap_should_client_block() where Apache decides
whether it should send the 100-Continue answer. As
r->expecting_100 (in fact, it's
new_uri->expecting_100 which was initialized above)
is always zero, the 100-Continue won't be sent.

Note that the expecting_100 flag is correctly copied in
http_protocol.c:ap_set_sub_req_protocol. My guess is that it was just
missing on the internal_internal_redirect().

SOLUTION

I added a line to copy  the status of r->expecting_100 to
new_uri->expecting_100.

After applying my patch, I could get a 100-Continue answer while making a
POST or a PUT. When trying to do so with a HEAD or GET request, I
didn't get any 100-Continue, as Roy's overrode this header (as
expected :)). 

I didn't push the tests to see how it works while using a proxy.

I hope that this modest contribution is helpful to the Apache team.

Cheers,

-Jose Kahan (jose@w3.org)

PATCH
=====================

*** http_request.c.new  Wed Jan 27 00:00:49 1999
--- http_request.c      Tue Jan 26 23:42:44 1999
*************** static request_rec *internal_internal_re
*** 1298,1304 ****
  
      new->htaccess        = r->htaccess;
      new->no_cache        = r->no_cache;
-     new->expecting_100   = r->expecting_100;
      new->no_local_copy   = r->no_local_copy;
      new->read_length     = r->read_length;     /* We can only read it
once */
      new->vlist_validator = r->vlist_validator;
--- 1298,1303 ----