Backend responding with 100 Continue results in the actual response being lost

I’m using nginx as a reverse proxy, configured to use HTTP 1.1 so as to
support range requests. The server responds to some of the requests with
a
“100 Continue”, even if there was no “Expect: 100-continue” in the
request.
The server then proceeds to read the rest of the request and,
eventually,
sends the “200 OK” reponse.

In my testing, in this scenario Nginx will forward the 100 Continue to
the
requesting browser, but the 200 OK response never makes it. It seems to
be
silently dropped. The result is that the browser is stuck waiting for a
response until the request times out.

Is this expected behaviour? From my reading of the HTTP 1/1 spec, this
server is not in violation of the spec. I’m using v1.4.2 on Windows.

Posted at Nginx Forum:

Hello!

On Mon, Jul 22, 2013 at 08:20:04PM -0400, rstarkov wrote:

Is this expected behaviour? From my reading of the HTTP 1/1 spec, this
server is not in violation of the spec. I’m using v1.4.2 on Windows.

As of now nginx doesn’t know how to handle 1xx informational
responses, and it always removes Expect from a requests sent to
backends due to this. RFC 2616 say:

    An origin server SHOULD NOT send a 100 (Continue) response if
    the request message does not include an Expect request-header
    field with the "100-continue" expectation, and MUST NOT send a
    100 (Continue) response if such a request comes from an HTTP/1.0
    (or earlier) client.

That is, it’s 100 Continue isn’t expected to be returned to nginx
from a complaint HTTP/1.1 server even if a request is via
HTTP/1.1.

If your backend server returns 100 Continue for some reason, you
may try switching proxy_http_version back to 1.0 as by default.
Most of HTTP servers are capable of handling Range requests via
HTTP/1.0 as well, you shouldn’t need HTTP/1.1 for Range requests
to work.


Maxim D.
http://nginx.org/en/donation.html

Hello Maxim,

Thanks for your recommendations. I realise that what this server is
doing is
a bit unusual, however:

That is, it’s 100 Continue isn’t expected to be returned to nginx
from a complaint HTTP/1.1 server even if a request is via
HTTP/1.1.

I just wanted to clarify that the server is conditionally compliant
with
HTTP/1.1, since this is a “SHOULD” requirement. Would be nice if this
were
supported, since otherwise you get timeouts that are very hard to
explain
and debug (but are easily attributable to nginx’s proxying).

In any case. I’m glad I got to the bottom of this very puzzling issue,
and
that future googlers will finally find something when googling for
“nginx
100 continue timeout”.

Posted at Nginx Forum:

Hello,
I’ve made a patch for this issue a while ago:
http://mailman.nginx.org/pipermail/nginx-devel/2012-December/003152.html

Best regards,
Piotr S.

Hello!

On Tue, Jul 23, 2013 at 06:47:46PM -0700, Piotr S. wrote:

Hello,
I’ve made a patch for this issue a while ago:
[PATCH] Ignore unexpected 1xx status messages from the upstream.

I believe I’ve already reviewd this patch and explained why it’s
wrong.


Maxim D.
http://nginx.org/en/donation.html

Hey Maxim,

I’ve made a patch for this issue a while ago:
[PATCH] Ignore unexpected 1xx status messages from the upstream.

I believe I’ve already reviewd this patch and explained why it’s
wrong.

Yes, you did… But fixing it ended very low on my TODO list.

I just pointed it to rstarkov, because it seems that he could use
working patch right now.

Best regards,
Piotr S.