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

2974d09ac2541e892966b762aad84943?d=identicon&s=25 rstarkov (Guest)
on 2013-07-23 02:21
(Received via mailing list)
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:
http://forum.nginx.org/read.php?2,241130,241130#msg-241130
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2013-07-23 13:21
(Received via mailing list)
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 Dounin
http://nginx.org/en/donation.html
2974d09ac2541e892966b762aad84943?d=identicon&s=25 rstarkov (Guest)
on 2013-07-23 13:53
(Received via mailing list)
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:
http://forum.nginx.org/read.php?2,241130,241142#msg-241142
A08bbb8c4c6036715c506cef5e5bbe84?d=identicon&s=25 Piotr Sikora (Guest)
on 2013-07-24 03:48
(Received via mailing list)
Hello,
I've made a patch for this issue a while ago:
http://mailman.nginx.org/pipermail/nginx-devel/201...

Best regards,
Piotr Sikora
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2013-07-24 09:34
(Received via mailing list)
Hello!

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

> Hello,
> I've made a patch for this issue a while ago:
> http://mailman.nginx.org/pipermail/nginx-devel/201...

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

--
Maxim Dounin
http://nginx.org/en/donation.html
A08bbb8c4c6036715c506cef5e5bbe84?d=identicon&s=25 Piotr Sikora (Guest)
on 2013-07-24 09:45
(Received via mailing list)
Hey Maxim,

>> I've made a patch for this issue a while ago:
>> http://mailman.nginx.org/pipermail/nginx-devel/201...
>
> 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 Sikora
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.