Bug 57853 - mod_proxy_http sends request with header 'Expect: 100-continue' and not-empty body.
Summary: mod_proxy_http sends request with header 'Expect: 100-continue' and not-empty...
Status: RESOLVED DUPLICATE of bug 60330
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_http (show other bugs)
Version: 2.4.7
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2015-04-24 08:15 UTC by Dmitry Shmyglev
Modified: 2018-07-04 21:05 UTC (History)
1 user (show)

tcpdump showing an error (4.07 KB, application/x-pcapng)
2015-04-24 08:15 UTC, Dmitry Shmyglev

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Shmyglev 2015-04-24 08:15:30 UTC
Created attachment 32684 [details]
tcpdump showing an error


I used apache with mod_proxy_http as load balancer.
When client sends POST-request to my server, apache added header 'Expect: 100-continue' into it and redirect to application server (jetty).

Thus the body of the POST-message is sent in the same frame. 
That is apache doesn't wait for the '100-continue'-response before sending a body of the message.

But RFC-7231 says that in this case the server can, but isn't obliged, to answer 100-continue:
   o  A server MAY omit sending a 100 (Continue) response if it has
      already received some or all of the message body for the
      corresponding request, or if the framing indicates that there is
      no message body.

If server does not respond 100-continue for this request, apache waits for a small timeout and respond to client 'server not avaiable'

I started discussion with jetty about this problem, link to it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=464797

I reproduced this error locally and attached tcpdump, please, look at it.

packet#4: client sent request.
packat#13: apache added header 'Excpect: 100-continue' and resended it to jetty (request for 100-continue and body in same frame).
packet#16: apache returned error to client: 'timeout awaiting 100-continue'
packet#22: jetty returned HTTP-200 OK
Comment 1 Yann Ylavic 2015-05-10 22:14:01 UTC
According to tcpdump, it seems you have configured either ProxyPass or BalancerMember with the parameter ping=1.

The ping parameter gives the time to wait for *any* response (timeout), hopefully a "100 Continue", but if another status is received instead, it will still be forwarded to the client as is (thus, mod_proxy_http does not explicitely wait for a "100 Continue" but for any response within the ping timeout).
The purpose of ping is that if a timeout occurs (before receiving any response), the same request can be retried with an other balancer member (if any).

With ping=1, this leaves only one second to the backend to respond, whereas in the trace we can see that the response takes a little more than that (the difference bewteen frame 16 and 13 is ~1.018s), hence the connection close before the (ignored) reponse.

However, I agree that mod_proxy should not send both the HTTP header and the body (full request) when ping is configured, otherwise it cannot send the same (likely non idempotent) request to another backend, even if a timeout (or 503) occured.
I am working on a fix regarding this (both end-to-end and ping 100-continue).

But I guess it won't fix your issue which probably requires that you use a higher ping timeout, since the backend needs more than that to generate a response.
Comment 2 Michael Osipov 2018-07-04 16:00:34 UTC
I believe that this is a dup of 60330.
Comment 3 Yann Ylavic 2018-07-04 21:05:01 UTC
Not exactly a duplicate but the patch trying to address 100-continue issues and RFC conformance (discussed here) is proposed there. So marking this one as duplicate to continue discussions and proposals in a single place.

*** This bug has been marked as a duplicate of bug 60330 ***