GithubHelp home page GithubHelp logo

adamfisk / littleproxy Goto Github PK

View Code? Open in Web Editor NEW
2.0K 2.0K 776.0 7.22 MB

High performance HTTP proxy originally written by your friends at Lantern and now maintained by a stellar group of volunteer open source programmers.

Home Page: https://www.getlantern.org

License: Apache License 2.0

Shell 0.05% ApacheConf 0.64% Nginx 0.12% JavaScript 0.09% HTML 33.15% PHP 43.67% Java 22.27%

littleproxy's Introduction

Build Status

LittleProxy is a high performance HTTP proxy written in Java atop Trustin Lee's excellent Netty event-based networking library. It's quite stable, performs well, and is easy to integrate into your projects.

One option is to clone LittleProxy and run it from the command line. This is as simple as:

$ git clone git://github.com/adamfisk/LittleProxy.git
$ cd LittleProxy
$ ./run.bash

You can embed LittleProxy in your own projects through Maven with the following:

    <dependency>
        <groupId>org.littleshoot</groupId>
        <artifactId>littleproxy</artifactId>
        <version>1.1.2</version>
    </dependency>

Once you've included LittleProxy, you can start the server with the following:

HttpProxyServer server =
    DefaultHttpProxyServer.bootstrap()
        .withPort(8080)
        .start();

To intercept and manipulate HTTPS traffic, LittleProxy uses a man-in-the-middle (MITM) manager. LittleProxy's default implementation (SelfSignedMitmManager) has a fairly limited feature set. For greater control over certificate impersonation, browser trust, the TLS handshake, and more, use a the LittleProxy-compatible MITM extension:

  • LittleProxy-mitm - A LittleProxy MITM extension that aims to support every Java platform including Android
  • mitm - A LittleProxy MITM extension that supports elliptic curve cryptography and custom trust stores

To filter HTTP traffic, you can add request and response filters using a HttpFiltersSource(Adapter), for example:

HttpProxyServer server =
    DefaultHttpProxyServer.bootstrap()
        .withPort(8080)
        .withFiltersSource(new HttpFiltersSourceAdapter() {
            public HttpFilters filterRequest(HttpRequest originalRequest, ChannelHandlerContext ctx) {
                return new HttpFiltersAdapter(originalRequest) {
                    @Override
                    public HttpResponse clientToProxyRequest(HttpObject httpObject) {
                        // TODO: implement your filtering here
                        return null;
                    }

                    @Override
                    public HttpObject serverToProxyResponse(HttpObject httpObject) {
                        // TODO: implement your filtering here
                        return httpObject;
                    }
                };
            }
        })
        .start();

Please refer to the Javadoc of org.littleshoot.proxy.HttpFilters to see the methods you can use.

To enable aggregator and inflater you have to return a value greater than 0 in your HttpFiltersSource#get(Request/Response)BufferSizeInBytes() methods. This provides to you a `FullHttp(Request/Response)' with the complete content in your filter uncompressed. Otherwise you have to handle the chunks yourself.

    @Override
    public int getMaximumResponseBufferSizeInBytes() {
        return 10 * 1024 * 1024;
    }

This size limit applies to every connection. To disable aggregating by URL at *.iso or *dmg files for example, you can return in your filters source a filter like this:

return new HttpFiltersAdapter(originalRequest, serverCtx) {
    @Override
    public void proxyToServerConnectionSucceeded(ChannelHandlerContext serverCtx) {
        ChannelPipeline pipeline = serverCtx.pipeline();
        if (pipeline.get("inflater") != null) {
            pipeline.remove("inflater");
        }
        if (pipeline.get("aggregator") != null) {
            pipeline.remove("aggregator");
        }
        super.proxyToServerConnectionSucceeded(serverCtx);
    }
};

This enables huge downloads in an application, which regular handles size limited FullHttpResponses to modify its content, HTML for example.

A proxy server like LittleProxy contains always a web server, too. If you get an URI without scheme, host and port in originalRequest it's a direct request to your proxy. You can return a HttpFilters implementation which answers responses with HTML content or redirects in clientToProxyRequest like this:

public class AnswerRequestFilter extends HttpFiltersAdapter {
	private final String answer;

	public AnswerRequestFilter(HttpRequest originalRequest, String answer) {
		super(originalRequest, null);
		this.answer = answer;
	}

	@Override
	public HttpResponse clientToProxyRequest(HttpObject httpObject) {
		ByteBuf buffer = Unpooled.wrappedBuffer(answer.getBytes("UTF-8"));
		HttpResponse response = new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.OK, buffer);
		HttpHeaders.setContentLength(response, buffer.readableBytes());
		HttpHeaders.setHeader(response, HttpHeaders.Names.CONTENT_TYPE, "text/html");
		return response;
	}
}

On answering a redirect, you should add a Connection: close header, to avoid blocking behavior:

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

With this trick, you can implement an UI to your application very easy.

If you want to create additional proxy servers with similar configuration but listening on different ports, you can clone an existing server. The cloned servers will share event loops to reduce resource usage and when one clone is stopped, all are stopped.

existingServer.clone().withPort(8081).start()

For examples of configuring logging, see src/test/resources/log4j.xml.

If you have questions, please visit our Google Group here:

https://groups.google.com/forum/#!forum/littleproxy

To subscribe, send an E-Mail to mailto:[email protected]. Simply answering, don't clicking the button, bypasses Googles registration process. You will become a member.

Benchmarking instructions and results can be found here.

Acknowledgments

Many thanks to The Measurement Factory for the use of Co-Advisor for HTTP standards compliance testing.

littleproxy's People

Contributors

adamfisk avatar ajayk avatar andrewtaylor avatar braisgabin avatar cispr avatar cstamas avatar danielkyu avatar detro avatar ganskef avatar javiersigler avatar jekh avatar kevg avatar leahxschmidt avatar makuk66 avatar mediumone avatar myleshorton avatar nasis avatar oxtoacart avatar philipa avatar ponomandr avatar qerub avatar rferreira avatar robux4 avatar schoeffm avatar shs96c avatar subnetmarco avatar techpavan avatar zdila avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

littleproxy's Issues

Use Travis CI for continuous integration

Travis CI is a very nice and easy integratable hosted continuous integration service. Just add a .travis.yml to the root of the project and register on the site, and Travis will build and run tests for each push.

Reverse proxy logs requests twice and processes responses twice

I would like to create a proxy that redirects every request made to 127.0.0.1:9000 to www.amazon.com. I wrote the following code, which also adds a x-test header to the response, but it shows two errors:

  • It seems like LittleProxy logs two incoming requests. The expected behavior would be to log only one request, the one incoming from 127.0.0.1:9000.
  • It also logs two responses, and it returns a double 'x-test` header in the same response. I have no idea why this is happening.

You can curl -i http://127.0.0.1:9000 after running the following code. The home page of www.amazon.com gets correctly loaded, but the anomalies still exist:

final HttpProxyServer server = new DefaultHttpProxyServer(9000,

    new HttpRequestFilter() {

        @Override
        public void filter(HttpRequest httpRequest) {
            httpRequest.setHeader("host", "www.amazon.com"); // Redirect every request to www.amazon.com
        }

    }, new HttpResponseFilters() {

        @Override
        public HttpFilter getFilter(String hostAndPort) {
            return new DefaultHttpFilter(new HttpResponseFilter() {

                @Override
                public HttpResponse filterResponse(HttpRequest arg0, HttpResponse arg1) {
                    arg1.addHeader("x-test", "yes");
                    return arg1;
                }

            }, new HttpRequestMatcher() {

                @Override
                public boolean filterResponses(HttpRequest arg0) {
                    return true;
                }

            });
        }

    });

server.start();

Accounting per authenticated user

I would like to user the GlobalTrafficShapingHandler to make accounting for authenticated user.
Scenario:
-User can only use an amount of MB per day/month
-Each time the user is connected and authenticated, the trafficShaper counts and checks the consumed volume
-If consumed volume threshold is reached, proxy blocks the traffic and redirect the user

How to do this feature with LittleProxy

SslLauncher throws SSLException

I started little proxy for http and I can intercept requests just fine.
When I start the SslLauncher and try to proxy requests via HTTPS I get this stacktrace:

$ java -Dlog4j.configuration=file:///home/jason/Projects/littleproxy/src/main/resources/log4j.properties -cp target/littleproxy-0.5-SNAPSHOT-jar-with-dependencies.jar:. org.littleshoot.proxy.SslLauncher 8989
About to start SSL server on port: 8989
0 2011-12-05 17:38:25,910 INFO [main] proxy.SelfSignedKeyStoreManager.resetStores (SelfSignedKeyStoreManager.java:40) - Not deleting keystore
About to start...
24 2011-12-05 17:38:25,934 INFO [main] proxy.DefaultHttpProxyServer.start (DefaultHttpProxyServer.java:121) - Starting proxy on port: 8989
29 2011-12-05 17:38:25,939 INFO [main] proxy.HttpServerPipelineFactory. (HttpServerPipelineFactory.java:89) - Creating server with keystore manager: org.littleshoot.proxy.SelfSignedKeyStoreManager@5b6df84b
59 2011-12-05 17:38:25,969 INFO [main] proxy.HttpServerPipelineFactory.setupJmx (HttpServerPipelineFactory.java:171) - Registering MBean with name: org.littleshoot.proxy:type=HttpServerPipelineFactory-HttpServerPipelineFactory202077946
3554 2011-12-05 17:38:29,464 INFO [New I/O server boss #1 ([id: 0x2b2d96f2, /0:0:0:0:0:0:0:0:8989])] proxy.HttpServerPipelineFactory.getPipeline (HttpServerPipelineFactory.java:207) - Accessing pipeline
3555 2011-12-05 17:38:29,465 INFO [New I/O server boss #1 ([id: 0x2b2d96f2, /0:0:0:0:0:0:0:0:8989])] proxy.HttpServerPipelineFactory.getPipeline (HttpServerPipelineFactory.java:209) - Adding SSL handler
3807 2011-12-05 17:38:29,717 INFO [New I/O server boss #1 ([id: 0x2b2d96f2, /0:0:0:0:0:0:0:0:8989])] proxy.HttpRequestHandler.setupJmx (HttpRequestHandler.java:179) - Registering MBean with name: org.littleshoot.proxy:type=HttpRequestHandler-HttpRequestHandler-1108966327
3812 2011-12-05 17:38:29,722 INFO [New I/O server boss #1 ([id: 0x2b2d96f2, /0:0:0:0:0:0:0:0:8989])] proxy.HttpRequestHandler.channelOpen (HttpRequestHandler.java:547) - New channel opened: [id: 0x0ffdadcd, /127.0.0.1:35237 => /127.0.1.1:8989]
3812 2011-12-05 17:38:29,722 INFO [New I/O server boss #1 ([id: 0x2b2d96f2, /0:0:0:0:0:0:0:0:8989])] proxy.HttpRequestHandler.channelOpen (HttpRequestHandler.java:550) - Now 1 browser to proxy channels...
3812 2011-12-05 17:38:29,722 INFO [New I/O server boss #1 ([id: 0x2b2d96f2, /0:0:0:0:0:0:0:0:8989])] proxy.HttpRequestHandler.channelOpen (HttpRequestHandler.java:552) - Now this class has 1 browser to proxy channels...
3819 2011-12-05 17:38:29,729 INFO [New I/O server worker #1-1] proxy.HttpRequestHandler.exceptionCaught (HttpRequestHandler.java:664) - Caught an exception on browser to proxy channel: [id: 0x0ffdadcd, /127.0.0.1:35237 => /127.0.1.1:8989]
javax.net.ssl.SSLException: not an SSL/TLS record: 47455420687474703a2f2f7777772e61746c616e746963706163696669636d6f7274676167652e636f6d2f686f6d652e68746d20485454502f312e310d0a557365722d4167656e743a206375726c2f372e32312e3320287838365f36342d70632d6c696e75782d676e7529206c69626375726c2f372e32312e33204f70656e53534c2f302e392e386f207a6c69622f312e322e332e34206c696269646e2f312e31380d0a486f73743a207777772e61746c616e746963706163696669636d6f7274676167652e636f6d0d0a4163636570743a202a2f2a0d0a50726f78792d436f6e6e656374696f6e3a204b6565702d416c6976650d0a0d0a
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:591)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:351)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:202)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
3822 2011-12-05 17:38:29,732 INFO [New I/O server worker #1-1] proxy.ProxyUtils.closeOnFlush (ProxyUtils.java:338) - Closing on flush: [id: 0x0ffdadcd, /127.0.0.1:35237 => /127.0.1.1:8989]
3827 2011-12-05 17:38:29,737 INFO [New I/O server worker #1-1] proxy.HttpRequestHandler.channelClosed (HttpRequestHandler.java:564) - Channel closed: [id: 0x0ffdadcd, /127.0.0.1:35237 :> /127.0.1.1:8989]
3828 2011-12-05 17:38:29,738 INFO [New I/O server worker #1-1] proxy.HttpRequestHandler.channelClosed (HttpRequestHandler.java:567) - Now 0 total browser to proxy channels...
3828 2011-12-05 17:38:29,738 INFO [New I/O server worker #1-1] proxy.HttpRequestHandler.channelClosed (HttpRequestHandler.java:569) - Now this class has 0 browser to proxy channels...
3828 2011-12-05 17:38:29,738 INFO [New I/O server worker #1-1] proxy.HttpRequestHandler.channelClosed (HttpRequestHandler.java:575) - Closing all proxy to web channels for this browser to proxy connection!!!

Empty ChannelBuffer on larger data

Hi,

I have a problem that might not be due to LittleProxy but it's the closest approximation:

I'm intercepting XMLHttpRequests from the browser with a request filter. The requests are POSTs. It works well when the content data is small but fails when it gets slightly larger, i.e. tens of kilobytes.

Basically, I'm getting BigEndianHeapChannelBuffer(ridx=0, widx=0, cap=0) from HttpRequest#getContent.

It may be LittleProxy, it may be netty, or it may be that I misunderstood something in how netty's channels work. In any case, I would appreciate any help or hints.

Thanks!

HTTP CONNECT requests fail when LittleProxy is chained to another proxy

If you run LittleProxy as HTTPS proxy and set an upstream proxy server using the HttpProxyServer.chainProxyHostAndPort field, LittleProxy will fail to serve HTTP CONNECT requests (such as https://www.google.com) because these HTTP requests are not sent to the upstream proxy server.

The solution would be to modify the HttpRequestHandler class accordingly:

private int writeConnectResponse(final ChannelHandlerContext ctx, 
        final HttpRequest httpRequest, final Channel outgoingChannel) {

  ...
            ctx.getPipeline().addLast("handler", 
                new HttpConnectRelayingHandler(outgoingChannel, this.channelGroup));

            if (chainProxyHostAndPort != null) {
                // forward the CONNECT request to the upstream proxy server which will return a HTTP response
                outgoingChannel.getPipeline().addBefore("handler", "encoder", new HttpRequestEncoder());
                outgoingChannel.write(httpRequest).addListener(new ChannelFutureListener() {
                    @Override
                    public void operationComplete(ChannelFuture future) throws Exception {
                        outgoingChannel.getPipeline().remove("encoder");
                    }
                });
            } else {
                final String statusLine = "HTTP/1.1 200 Connection established\r\n";
                ProxyUtils.writeResponse(browserToProxyChannel, statusLine, 
                    ProxyUtils.CONNECT_OK_HEADERS);
            }

  ...

}

Maybe my change on this method is not the best place to insert this fix; I guess the HttpRequestHandler.OnConnect.onConnect() would suit better. I've made the change on HttpRequestHandler.writeConnectResponse() as there is some port filtering rule and it's not useful to forward the CONNECT request if it gets rejected by LittleProxy.

Construct a unit test for testing idle handling on client->proxy and proxy->server side

We recently found a bug in our idle handling. It would be nice to have a unit test to make sure it's working correctly. For this test to be feasible, we need to add a facility to make the timeout configurable. We can make our Jetty test server sleep for some period longer than the timeout to test the proxy->server side. On the client->proxy side, if we can't find a way to make HttpClient idle, we can just open a straight URLConnection instead.

Allow more sophisticated proxy rules

Along the lines of dansguardian for squid -- thanks to Ashish:

 <category name="videosites" action="warn">
  <rule>        <url> youtube.com </url>
  </rule>
  <rule>        <urlpattern> *video*.* </urlpattern>
  </rule>
</category>

another action.xml file contains

  <action name="warn" log="yes">
       <message> the URL $url you are visting is not productive to this network. It falls in ${category.name} category. Do you still want to visit? Click yes or no
       </message>
   </action>

<action name="block" log="yes">
       <message> the URL $url you are visting is not productive to office usage. It falls in ${category.name} category. It is blocked.
       </message>
   </action>

</actions>

OSGI integration

I am willing to run LittleProxy inside an OSGI container for test purpose. However, the current JAR does not contain the needed OSGI metadata (Bundle identifier, Export-Packages, Import-Packages). They can be generated by the Maven Felix Bundle plugin

Error with chunked requests throwing NullPointerException

From Petr Ferschmann in the forum:

java.lang.NullPointerException
at org.littleshoot.proxy.HttpRequestHandler.processChunk(HttpRequestHandler.java:227)
at org.littleshoot.proxy.HttpRequestHandler.messageReceived(HttpRequestHandler.java:208)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.unfoldAndFireMessageReceived(ReplayingDecoder.java:520)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:506)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:443)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:321)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)

It is because of the separation of messages in org.jboss.netty.handler.codec.http.HttpRequestDecoder (see parameter maxChunkSize).
Problem is that connection to the server is not yet established and we receive data (it splits content into chunks). If you use maxChunkSize large enough you may not find such a error. Or if you use real chunks.

Here is patch:

Index: org/littleshoot/proxy/HttpRequestHandler.java

--- org/littleshoot/proxy/HttpRequestHandler.java (revision 22737)
+++ org/littleshoot/proxy/HttpRequestHandler.java (working copy)
@@ -315,7 +314,6 @@
else {
log.info("Establishing new connection");
final ChannelFuture cf;

  •        ctx.getChannel().setReadable(false);
         try {
             cf = newChannelFuture(request, inboundChannel, hostAndPort);
         } catch (final UnknownHostException e) {
    
    @@ -348,15 +345,8 @@
    log.info("Finished write: "+wcf+ " to: "+
    request.getMethod()+" "+
    request.getUri());
  •                           ctx.getChannel().setReadable(true);
                         }
                     });
    
  •                    currentChannelFuture = wf;
                 }
                 else {
                     log.info("Could not connect to " + hostAndPort,
    

Differences between 0.3 and 0.4?

The pre-git version (0.3) was working fine as I could do a 'curl -x localhost:8080 ' to proxy requests. However, with the latest on github, curl fails with connection refused errors. Are there any known issues?

Thanks
Subbu

Error in connection counting

In logs I found following:

37413336 [New I/O server worker #1-3] WARN org.littleshoot.proxy.HttpRequestHandler - Closing all proxy to web channels for this browser to proxy connection!!!
37413336 [New I/O client worker #1-3] WARN org.littleshoot.proxy.HttpRelayingHandler - Closing browser to proxy channel: [id: 0x0102401e, /172.16.10.35:50880 :> /172.16.10.50:9090]
37413336 [New I/O client worker #1-3] ERROR org.littleshoot.proxy.HttpRequestHandler - Something's amiss. We have -1 and 0 connections stored

What made me worried is last line: "We have -1 and 0 conn...".
Apparently this should not happen.
I've tried fixing it in our clone: https://github.com/sourcesense/LittleProxy
Though we still see this error.

Please help in fixing it.

HttpRequest to the another proxy server

Hello!

Could you please give advice, how to redirect HttpRequest to the another proxy server.
Which will classes need to use, which apзroach will better?

Example:
public static void main(String[] args) {
final HttpProxyServer server =
new DefaultHttpProxyServer(3128, new HttpRequestFilter() {
@OverRide
public void filter(HttpRequest httpRequest) {
//HOW TO redirect request to the another proxy ? for example "194.44.34.100"
}
},
new HttpResponseFilters() {
@OverRide
public HttpFilter getFilter(String hostAndPort) {
return null;
}
}
);
Regards!

Could not find artifact org.dnsjava:dnsjava:jar:2.1.3 in central

When I do fresh checkout of "master" branch and run build I get this:

$ mvn clean compile
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building LittleProxy 0.5-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://oss.sonatype.org/content/repositories/snapshots/org/littleshoot/dnssec4j/0.1-SNAPSHOT/maven-metadata.xml
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/org/littleshoot/dnssec4j/0.1-SNAPSHOT/maven-metadata.xml (767 B at 0.3 KB/sec)
Downloading: https://oss.sonatype.org/content/repositories/snapshots/org/littleshoot/dnssec4j/0.1-SNAPSHOT/dnssec4j-0.1-20120205.033959-8.pom
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/org/littleshoot/dnssec4j/0.1-SNAPSHOT/dnssec4j-0.1-20120205.033959-8.pom (9 KB at 3.4 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/dnsjava/dnsjava/2.1.3/dnsjava-2.1.3.pom
[WARNING] The POM for org.dnsjava:dnsjava:jar:2.1.3 is missing, no dependency information available
Downloading: https://oss.sonatype.org/content/repositories/snapshots/org/littleshoot/dnssec4j/0.1-SNAPSHOT/dnssec4j-0.1-20120205.033959-8.jar
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/org/littleshoot/dnssec4j/0.1-SNAPSHOT/dnssec4j-0.1-20120205.033959-8.jar (12 KB at 6.1 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/dnsjava/dnsjava/2.1.3/dnsjava-2.1.3.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.874s
[INFO] Finished at: Thu Mar 08 22:09:20 CET 2012
[INFO] Final Memory: 11M/132M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project littleproxy: Could not resolve dependencies for project org.littleshoot:littleproxy:bundle:0.5-SNAPSHOT: Could not find artifact org.dnsjava:dnsjava:jar:2.1.3 in central (http://repo1.maven.org/maven2) -> [Help 1]

The commit is 4a99219

a bug with version 0.5, help

i use redsock and littleproxy in my localhost,

use iptables to direct all port 80 to redsock, and redsock push the data to littleproxy,

when i use littleproxy 0.4 ,it works fine, here is the snapshot image:

1

but when is use littleproxy 0.5 , the snapshot image:

2

look at the red border area, the first snapshot load the image ,but the second can't , this matter does not appear regular 。
why? is it the bug with 0.5?

Erro pom

[INFO] Scanning for projects...
[WARNING] POM for 'biz.aQute:bndlib:pom:1.50.0:runtime' is invalid.

Its dependencies (if any) will NOT be available to the current build.
[INFO] ------------------------------------------------------------------------
[INFO] Building LittleProxy
[INFO] task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] 'jar-no-fork' was specified in an execution, but not found in the plugin
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Sep 12 13:50:02 BRT 2012
[INFO] Final Memory: 15M/151M
[INFO] ------------------------------------------------------------------------
Could not package

DefaultHttpProxy leaves infinite alive non-daemon threads after stopping

Note: Previously called "DefaultHttpProxyServer does not stop"
I have tried to write a simple test using DefaultHttpProxyServer, but can not managed to stop it (underlying threads still live after returning from the stop() methods - especially some "Hashed wheel timer" live forever while two other threads terminate after about a minute after stopping ProxyServer)

My code is here:
https://gist.github.com/2836705

Is it a bug or I'm missing something? If proxy is not used at all it does stop normally.

P.S. The two tests using different http client libraries are absolutely independent, but share the same behaviour - comment please on the one you like better.

NPE when chunks arrive in requests before we've established outgoing connection futures.

See Sezgin's forum post at https://groups.google.com/forum/#!topic/littleproxy/wA483JInBmc


java.lang.NullPointerException
at org.littleshoot.proxy.HttpRequestHandler.processChunk(HttpRequestHandler.java:225)
at org.littleshoot.proxy.HttpRequestHandler.messageReceived(HttpRequestHandler.java:206)
at org.jboss.netty.handler.timeout.IdleStateAwareChannelHandler.handleUpstream(IdleStateAwareChannelHandler.java:43)
at org.jboss.netty.handler.timeout.IdleStateHandler.messageReceived(IdleStateHandler.java:270)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:420)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:538)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:437)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

Possible for proxy to freeze apparently on out-of-sync message reading

This has appeared apparently in particular with HTTP CONNECT messages where it looks like incoming data from the HTTP request body is read as requests, causing overall request reading to get out of sync.

Possibly the result of large file uploads?

Maybe we can add a test of a large data upload of random in-memory data to some special /dev/null-like destination?

a bug with version 0.5, help

i use redsock and littleproxy in my localhost,

use iptables to direct all port 80 to redsock, and redsock push the data to littleproxy,

when i use littleproxy 0.4 ,it works fine, here is the snapshot image:

1

but when is use littleproxy 0.5 , the snapshot image:

2

look at the red border area, the first snapshot load the image ,but the second can't , this matter does not appear regular 。
why? is it the bug with 0.5?

java.lang.NumberFormatException using IPv6 addresses

Hi,
I'm using version 0.4. The HttpRequestHandler chokes on IPv6 addresses:

2012-03-15 18:49:52,095 INFO [org.littleshoot.proxy.HttpRequestHandler:607] Caught an exception on browser to proxy channel: [id: 0x27972e3a, /0:0:0:0:0:0:0:1:49725 => /0:0:0:0:0:0:0:1:19385]
java.lang.NumberFormatException: For input string: ":1]:8080"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:449)
at java.lang.Integer.parseInt(Integer.java:499)
at org.littleshoot.proxy.HttpRequestHandler.newChannelFuture(HttpRequestHandler.java:450)
at org.littleshoot.proxy.HttpRequestHandler.processMessage(HttpRequestHandler.java:321)
at org.littleshoot.proxy.HttpRequestHandler.messageReceived(HttpRequestHandler.java:213)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.unfoldAndfireMessageReceived(ReplayingDecoder.java:522)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:506)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:443)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:280)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:200)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Below is a patch for solving this:

diff --git a/src/main/java/org/littleshoot/proxy/HttpRequestHandler.java b/src/main/java/org/littleshoot/proxy/HttpRequestHandler.java
index 864b7f0..7563207 100644
--- a/src/main/java/org/littleshoot/proxy/HttpRequestHandler.java
+++ b/src/main/java/org/littleshoot/proxy/HttpRequestHandler.java
@@ -443,15 +443,30 @@ public class HttpRequestHandler extends SimpleChannelUpstreamHandler
final Channel browserToProxyChannel) {
final String host;
final int port;

  •    if (hostAndPort.contains(":")) {
    
  •        host = StringUtils.substringBefore(hostAndPort, ":");
    
  •        final String portString = 
    
  •            StringUtils.substringAfter(hostAndPort, ":");
    
  •        port = Integer.parseInt(portString);
    
  •    }
    
  •    else {
    
  •        host = hostAndPort;
    
  •        port = 80;
    
  •    if (hostAndPort.contains("[") && hostAndPort.contains("]")) {
    
  •       int idx = hostAndPort.lastIndexOf("]");
    
  •       int cIdx = hostAndPort.lastIndexOf(":");
    
  •       if (cIdx > idx) {
    
  •          host = hostAndPort.substring(0, idx + 1);
    
  •          final String portString = 
    
  •              hostAndPort.substring(cIdx + 1);
    
  •          port = Integer.parseInt(portString);
    
  •       }
    
  •       else {
    
  •          host = hostAndPort;
    
  •          port = 80;
    
  •       }
    
  •    } else {
    
  •       if (hostAndPort.contains(":")) {
    
  •           host = StringUtils.substringBefore(hostAndPort, ":");
    
  •           final String portString = 
    
  •               StringUtils.substringAfter(hostAndPort, ":");
    
  •           port = Integer.parseInt(portString);
    
  •       }
    
  •       else {
    
  •           host = hostAndPort;
    
  •           port = 80;
    
  •       }
     }
    
     // Configure the client.
    

Please evaluate.
Thanks

Decrease log level of some log messages

Currently all log messages are of level INFO, WARN or ERROR. Some of these would be better classified as DEBUG or TRACE, e.g. the logging of HTTP requests; it doesn't make sense to have such detailed messages at INFO level.

Integrate DNSSEC into all DNS lookups

In collaboration with NLNet, the LittleShoot team will be integrating DNS sec into all DNS lookups in LittleProxy. We will make this configurable from littleproxy.properties, and we will likely make DNSSEC resolution the default on startup.

DNS lookup issues

We might want to always use Google DNS?

See the following:

Host: p.twitter.com
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17
Accept: /
Referer: http://platform.twitter.com/widgets/tweet_button.1362008198.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: pid=v3:1362078050924654619992944 on channel: [id: 0x4bf3258f, /69.121.98.226:45615 => /10.207.42.36:7777]
1802381650 2013-02-28 19:16:57,948 DEBUG [New I/O worker #5] proxy.HttpRequestHandler.processRequest (HttpRequestHandler.java:448) - Establishing new connection
1802381650 2013-02-28 19:16:57,948 DEBUG [New I/O worker #5] proxy.HttpRequestHandler.newChannelFuture (HttpRequestHandler.java:706) - Starting new connection to: p.twitter.com
1802381650 2013-02-28 19:16:57,948 WARN [New I/O worker #5] proxy.HttpRequestHandler.processRequest (HttpRequestHandler.java:454) - Could not resolve host?
java.net.UnknownHostException: p.twitter.com
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:850)
at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1201)
at java.net.InetAddress.getAllByName0(InetAddress.java:1154)
at java.net.InetAddress.getAllByName(InetAddress.java:1084)
at java.net.InetAddress.getAllByName(InetAddress.java:1020)
at java.net.InetAddress.getByName(InetAddress.java:970)
at org.littleshoot.proxy.HttpRequestHandler.newChannelFuture(HttpRequestHandler.java:713)
at org.littleshoot.proxy.HttpRequestHandler.processRequest(HttpRequestHandler.java:452)
at org.littleshoot.proxy.HttpRequestHandler.messageReceived(HttpRequestHandler.java:277)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787)
at org.jboss.netty.channel.SimpleChannelHandler.messageReceived(SimpleChannelHandler.java:142)
at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
at org.jboss.netty.handler.timeout.IdleStateAwareChannelHandler.handleUpstream(IdleStateAwareChannelHandler.java:36)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787)
at org.jboss.netty.handler.timeout.IdleStateHandler.messageReceived(IdleStateHandler.java:294)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:555)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
1802381653 2013-02-28 19:16:57,951 DEBUG [New I/O worker #5] proxy.HttpRequestHandler.channelClosed (HttpRequestHandler.java:755) - Channel closed: [id: 0x4bf3258f, /69.121.98.226:45615 :> /10.207.42.36:7777]

Error in connection close handling logic

There's an issue where the browser/client will open a single connection to LittleProxy and send multiple requests through it. That results in multiple connections to external servers. Then, when one of those servers indicates the end of an HTTP response body through closing the connection we don't necessarily close the connection to the browser because in some cases there are still other outgoing connections associated with that single browser/client connection.

I'm not sure what the optimal solution is to this problem. Maybe if those other connections have all sent responses we can close it? Maybe we simply wait for all those responses before the close?

LittleProxy does not work when accessing m38v file (http streaming files)

Hello,
I would like to use LittleProxy but i have a big pb when i try to
access video files (http streaming) with m38v format (Apple http
streaming format).
I'm using your proxy without any modification.

Any idea regarding this pb ?

The video can be accessible from iPhone/iPad/SafariMacOS at :
http://payment.demo.alcatel-lucent.com/demo/index2.html

Thanks in advance

Fred
.
The exception stack:

java.nio.channels.ClosedChannelException
at
org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:
629)
at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:
605)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:
119)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:
76)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:
60)
at
org.jboss.netty.handler.traffic.AbstractTrafficShapingHandler.handleDownstream(AbstractTrafficShapingHandler.java:
507)
at org.jboss.netty.channel.Channels.close(Channels.java:720)
at org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:
208)
at
org.littleshoot.proxy.HttpRequestHandler.onRelayChannelClose(HttpRequestHandler.java:
482)
at
org.littleshoot.proxy.HttpRelayingHandler.channelClosed(HttpRelayingHandler.java:
214)
at
org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(ReplayingDecoder.java:
555)
at
org.jboss.netty.handler.codec.replay.ReplayingDecoder.channelClosed(ReplayingDecoder.java:
456)
at org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:
404)
at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:
606)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:
356)
at
org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:
281)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:
201)
at
org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:
46)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
21 févr. 2011 12:28:42,224 - WARN [New I/O client worker #1-1] -
proxy.HttpRequestHandler - Channel closed: [id: 0x0180cf2a, /
192.168.1.20:59200 :> /192.168.1.95:13585]
21 févr. 2011 12:28:42,224 - INFO [New I/O client worker #1-1] -
proxy.HttpRequestHandler - Now 0 total browser to proxy channels...
21 févr. 2011 12:28:42,224 - INFO [New I/O client worker #1-1] -
proxy.HttpRequestHandler - Now this class has 0 browser to proxy
channels...
21 févr. 2011 12:28:42,224 - WARN [New I/O client worker #1-1] -
proxy.HttpRequestHandler - Closing all proxy to web channels for this
browser to proxy connection!!!
21 févr. 2011 12:28:42,224 - INFO [New I/O client worker #1-1] -
proxy.HttpRequestHandler - WEB CONNECTIONS COUNTS IN SYNC

Support streaming filtering

Currently, HttpFilters used for both request and response filtering, automatically cause chunked transfers to be buffered prior to being passed to the filter. This is very memory intensive and is often unnecessary. Imagine for instance a filter that's simply inspecting/modifying request or response headers.

LittleProxy should instead pass all chunks (as HttpObjects) to the HttpFilter as they arrive. Filters that have a need for buffering should implement this themselves, perhaps with the aid of a facility from LittleProxy in the form of a BufferedHttpFilter base class or something like that.

a bug with version 0.5, help

i use redsock and littleproxy in my localhost,

use iptables to direct all port 80 to redsock, and redsock push the data to littleproxy,

when i use littleproxy 0.4 ,it works fine, here is the snapshot image:

1

but when is use littleproxy 0.5 , the snapshot image:

2

look at the red border area, the first snapshot load the image ,but the second can't , this matter does not appear regular 。
why? is it the bug with 0.5?

NetworkUtils not found

When running the app as a maven project using mvn clean install, NetworkUtils is not found.

symbol: variable NetworkUtils
location: class org.littleshoot.proxy.DefaultHttpProxyServer

Allow setting the cacheManager for HttpServerPipelineFactory

cacheManager for HttpServerPipelineFactory is private. There is no "good" way to use another cache implementation. No setters or even protected property.

I guess the solution is to add one constructor param for the cacheManager and modify the DefaultHttpProxyServer to supply the DefaultProxyCacheManager instance.

Memory leak after running for long periods of time, possibly related to large files.

We've experienced a memory leak in production where eventually LittleProxy will consume all of its heap space. Somehow accepted channels are not getting garbage collected in relay channels. I've attached a screenshot from Eclipse Memory Analyzer, but I just wanted to let everyone know we're aware of the problem and are giving it a closer look. Seems like it might be associated with proxying very large files.

eclipse-memory-analyzer-littleproxy

HttpServerPipelineFactory doesn't enforce an idle handler, though the client (DefaultRelayPipelineFactory) does

The DefaultRelayPipelineFactory, which is used by connections that go from proxy to the web, specifies an IdleStateHandler and an IdleAwareHandler. There are hardcoded values for read and write timeout of 40 seconds depending on the HTTP method specified (on a side note, this should probably be configurable, and there should probably be a read timeout on PUT and POST as well).

However, on the HttpServerPipelineFactory, there is no idle handling present.

What this means is that you can end up hanging forever on a connection. For example, let's say that Firefox is configured to use a proxy hitting a site called SlowWebsite. Firefox makes a connection to the proxy, which in turn makes a connection to SlowWebsite. SlowWebsite takes longer than 40 seconds to respond and the proxy terminates the connection due to idle state. SlowWebsite tries to respond after 60 seconds, and nothing happens. The connection between Firefox and the proxy is still present, resulting in Firefox never returning ready state for the page because the request is stuck in limbo.

Adding an IdleStateHandler and IdleAwareHandler at a slightly higher threshold (since setting the same would be problematic) in the HttpServerPipelineFactory.getChannel method fixes this issue for me.

On a side note, with the changes I have on my local machine, I also adding logging of the request and referrer to help me debug what resources might be latent if, say, a JavaScript file on a page is taking forever to download.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.