Answer redirect by filter for direct proxy requests trick is broken

[ganskef]

I've built a caching proxy server, which provides a Web UI for its contents or browsing history and for full text search results. This is implemented with filters which answers responses with content, errors or with a 302 Found state to redirect. Redirects are neccessary for the modify/redirect pattern. It works fine with LittleProxy up to 78e41b2.

@jekh I think it's introduced with #204. Please, have a look at this test. It's working in this branch, but it fails in master.

Update: fails means: the browser is not redirected to another URL and waits until timeout occours.

[jekh]

One of the changes in #204 is that connections won't be automatically closed after short-circuit responses. Generally this is a good thing, but if you were relying on the automatic connection closure to indicate "end-of-message", it may cause your responses to "hang". You can force LP to close the connection by adding the "Connection: close" header to your short-circuit responses. Alternately, you can enable chunked Transfer-Encoding, or set an appropriate Content-Length. See RFC 7230, section 3.3.3 for details on indicating message body length.

[ganskef]

Thank you, the redirect works well with:

HttpHeaders.setHeader(answer, Names.CONNECTION, Values.CLOSE);

A Content-Length is working only, if the message has a content, since a length of 0 hasn't worked for me.

[jekh]

Glad it's working for you. Content-Length of 0 should work, though (assuming there is no entity body on your message). What happened when you set Content-Length to 0?

[ganskef]

I've tried a redirect by a DefaultHttpResponse (no Full) without a content, without Connection: close header, but with Content-Length: 0 header. -> This won't fix the blocking behavior.

[jekh]

Did you try with a DefaultFullHttpResponse with a Content-Length: 0 header? It shouldn't make a difference if there is no entity content, but I'd like to investigate further. Did you have aggregation turned on (i.e. non-zero buffer values in the HttpFiltersSourceAdapter)?

The test you linked to earlier in this issue seems to be gone -- do you have a test or a snippet of code that you know hangs with Content-Length 0? I'd like to try to get it fixed, because always closing connections is not a very efficient way to use a proxy server. (As an alternative, for now, you could set the Transfer-Encoding to Chunked instead of adding the Connection: close header.)

[ganskef]

Hi Jason,

use this Test
https://github.com/ganskef/LittleProxy/blob/proxy_web_ui_test/src/test/java/org/littleshoot/proxy/ProxyWebUiTest.java
It's been renamed, see PR #224

Aggregation was off in the test, but it's always on in my proxy, where
I've tried it manually. Chunked should be set there, but it won't work
... means blocking occurs with redirect.

Answering content works well. So closing on redirect is not a problem
(for me).

Am 31.07.2015 um 16:53 schrieb Jason Hoetger:

Did you try with a DefaultFullHttpResponse with a Content-Length: 0
header? It /shouldn't/ make a difference if there is no entity content,
but I'd like to investigate further. Did you have aggregation turned on
(i.e. non-zero buffer values in the HttpFiltersSourceAdapter)?

The test you linked to earlier in this issue seems to be gone -- do you
have a test or a snippet of code that you know hangs with Content-Length
0? I'd like to try to get it fixed, because always closing connections
is not a very efficient way to use a proxy server. (As an alternative,
for now, you could set the Transfer-Encoding to Chunked instead of
adding the Connection: close header.)

—
Reply to this email directly or view it on GitHub
#222 (comment).