http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering
i can not understanding "When buffering is disabled, the request body is sent to the proxied server immediately as it is received. In this case, the request cannot be passed to the next server if nginx already started sending the request body."
what's mean "the request cannot be passed to the next server if nginx already started sending the request body"
If you have a service with multiple upstream servers, possibly for load balancing or resilience, and one of the upstream servers fail while Nginx is sending the request body to it, Nginx may try to use another server.
But it can only try another server if it has a complete copy of the original request body (i.e. request buffering enabled) or the client has not started sending the request body yet.
Related
I want to know one thing that is it possible for the NGINX to return the response of one upstream server to another upstream.
I need this as when a request is received I want to get it validated from one upstream server, and if validated then only let the NGINX forward that request to the second upstream server which hosts the main processing engine. And once processed by the second server, it replies back with HTTP response.
I have a demand, is at server return response, send a request to other server, but openresty say API disabled in the context of body_filter_by_lua*. i use module resty.http.
thanks
You can change the main logic.
First issue subrequest to your upstream (location.capture or lua-resty-http)
Upon success you may first send the response downstream by Lua code and issue the next subrequest to your "other server" from Lua.
UPDATE - this doesn't work
As second approach you may treat your "other server" as upstream and allow request to this upstream only if subrequest to original server will be successful.
For both scenarios you may use access_by_lua* and content_by_lua* where cosocket API is available.
These are both timeout errors, but who is timing out in a 408 vs. a 504?
From w3, 408 is defined as:
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
...And 504 is:
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
So who is the 'client' in the 408 if not an intermediary server? If it's an actual end user, how does a server know to wait for their request before they have made it?
The client is the browser or client application. The server knows to wait for a request because it has accepted a connection, or already read part of the request, say a header or two.
Amazon documentation tells: http://docs.aws.amazon.com/en_en/elasticloadbalancing/latest/classic/ts-elb-error-message.html#ts-elb-errorcodes-http408
Indicates that the client cancelled the request or failed to send a full request
Mozilla documentation tells: https://developer.mozilla.org/en/docs/Web/HTTP/Status/408
The HTTP 408 Request Timeout response status code means that the server would like to shut down this unused connection. It is sent on an idle connection by some servers, even without any previous request by the client
I'm trying to diagnose a web service that sits behind some load balancers and proxies. Under load, one of the servers along the way starts to return HTTP 504 errors, which indicates a gateway timeout. With that background out of the way, here is my question:
When a proxy makes a request to the destination server, and the destination server receives the request but doesn't respond in time (thus exceeding the timeout), resulting in a 504, what happens when the destination server does eventually respond? Does it know somehow that the requestor is no longer interested in a response? Does it happily send a response with no idea that the gateway already sent HTTP error response back to the client? Any insight would be much appreciated.
It's implementation-dependent, but any proxy that conforms to RFC 2616 section 8.1.2.1 should include Connection: close on the 504 and close the connection back to the client so it can no longer be associated with anything coming back from the defunct server connection, which should also be closed. Under load there is the potential for race conditions in this scenario so you could be looking at a bug in your proxy.
If the client then wants to make further requests it'll create a new connection to the proxy which will result in a new connection to the backend.
Imagine a webbrowser that makes an HTTP request to a remote server, such as site.example.com
If the browser is then configured to use a proxy server, let's call it proxy.example.com using port 8080, in which ways are the request now different?
Obviously the request is now sent to proxy.example.com:8080, but there must surely be other changes to enable the proxy to make a request to the original url?
RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Section 5.3.2. absolute-form:
When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target.
absolute-form = absolute-URI
The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.7.
An example absolute-form of request-line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
So, without proxy, the connection is made to www.example.org:80:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org
With proxy it is made to proxy.example.com:8080:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org
Where in the latter case the Host header is optional (for HTTP/1.0 clients), and must be recalculated by the proxy anyway.
The proxy simply makes the request on behalf of the original client. Hence the name "proxy", the same meaning as in legalese. The browser sends their request to the proxy, the proxy makes a request to the requested server (or not, depending on whether the proxy wants to forward this request or deny it), the server returns a response to the proxy, the proxy returns the response to the original client. There's no fundamental difference in what the server will see, except for the fact that the originating client will appear to be the proxy server. The proxy may or may not alter the request, and it may or may not cache it; meaning the server may not receive a request at all if the proxy decides to deliver a cached version instead.