There are some servers that don't obey non-body receiving responses, including:
Sending 0-length chunk on 304 Not Modified
Sending full response body in HEAD requests
Sometimes nginx forwards zero-length chunk but strips transfer-encoding at all (see #47)
(maybe other, but at least 204 codes should be immune to the attack).
While (1) only creates errors for some clients, (2) can really be source of cache-poisoning attacks. So we might want more careful mode for keep-alive/pipelineing:
Do not pipeline HEAD requests
No not pipeline If-Modifed-Since and If-None-Match requests, 304 response codes.
The alternative is to disable keep-alive by default as nginx does. Another thing is we need some test suite to determine whether service behind swindon does proxying correctly. And the test suite is hard to do because the service might have some complex routing (i.e. serving static files under certain urls, serving streaming updates under certain urls), or be non-validating proxy itself (i.e. depend on the services behind for correctness).
There are some servers that don't obey non-body receiving responses, including:
(maybe other, but at least 204 codes should be immune to the attack).
While (1) only creates errors for some clients, (2) can really be source of cache-poisoning attacks. So we might want more careful mode for keep-alive/pipelineing:
If-Modifed-SinceandIf-None-Matchrequests, 304 response codes.The alternative is to disable keep-alive by default as nginx does. Another thing is we need some test suite to determine whether service behind swindon does proxying correctly. And the test suite is hard to do because the service might have some complex routing (i.e. serving static files under certain urls, serving streaming updates under certain urls), or be non-validating proxy itself (i.e. depend on the services behind for correctness).
Inspired by #47.