Closed makmi closed 9 years ago
This is an interesting issue, @makmi. With the legacy implementation, you are setting downstreamKbps to 0 in order to "pause" traffic, preventing any data from getting through, is that right?
In the LittleProxy implementation, seting downstreamKbps to 0 will disable throttling, which explains why you're not seeing the behavior you expect. I'm actually not sure if it's possible to "pause" traffic using netty's GlobalTrafficShapingHandler (which LP uses for throttling), although it is possible to set it to 1 byte (rather than kb) per second, which would result in similar behavior.
Would a 1 byte/second limit satisfy your use case? Adding support for bytes/sec (rather than kbytes/second) to the REST API is relatively easy, whereas support for pausing entirely will be trickier.
Currently we switched to scenario where we start/stop proxy instance via REST to simulate device being 'disconnected' from network. This means we do not need to change bandwidth at this moment. Option for setting bandwidth to 1 byte per second seems a nice feature and if it were available we would use it in our tests in addition to stopping/starting the instance. At this moment we are fine with what we have right now.
Hi @makmi - I just added two parameters to the /limit endpoint: upstreamBps and downstreamBps. They will allow you to set bandwidth limits in bytes/sec instead of kbytes/sec, so hopefully this will allow you to effectively pause your requests/responses by setting the limit to 1 byte/second.
I'm going to go ahead and close this issue for now, but feel free to reopen if it doesn't work for you.
I am running browsermob-proxy-2.1.0-beta-1 from https://github.com/lightbody/browsermob-proxy/releases/download/browsermob-proxy-2.1.0-beta-1/browsermob-proxy-2.1.0-beta-1-bin.zip I am using https://github.com/jakubroztocil/httpie to send REST requests.
I execute following commands: $ cd browsermob-proxy-2.1.0-beta-1/bin $ ./browsermob-proxy --port 9090 --use-littleproxy=false
$ http --verbose -f POST http://localhost:9090/proxy port=9094 POST /proxy HTTP/1.1 Accept: / Accept-Encoding: gzip, deflate, compress Content-Length: 9 Content-Type: application/x-www-form-urlencoded; charset=utf-8 Host: localhost:9090 User-Agent: HTTPie/0.8.0
port=9094
HTTP/1.1 200 OK Content-Length: 13 Content-Type: application/json Server: Jetty(7.x.y-SNAPSHOT)
{ "port": 9094 }
$ http --verbose -f PUT http://localhost:9090/proxy/9094/limit downstreamKbps=100000 PUT /proxy/9094/limit HTTP/1.1 Accept: / Accept-Encoding: gzip, deflate, compress Content-Length: 21 Content-Type: application/x-www-form-urlencoded; charset=utf-8 Host: localhost:9090 User-Agent: HTTPie/0.8.0
downstreamKbps=100000
HTTP/1.1 200 OK Content-Length: 0 Content-Type: text/plain Server: Jetty(7.x.y-SNAPSHOT)
Than I set my mobile device (Android) to use the proxy instance on port: 9094 I can browse internet as regular user. Than I issue command: $ http --verbose -f PUT http://localhost:9090/proxy/9094/limit downstreamKbps=0 PUT /proxy/9094/limit HTTP/1.1 Accept: / Accept-Encoding: gzip, deflate, compress Content-Length: 16 Content-Type: application/x-www-form-urlencoded; charset=utf-8 Host: localhost:9090 User-Agent: HTTPie/0.8.0
downstreamKbps=0
HTTP/1.1 200 OK Content-Length: 0 Content-Type: text/plain Server: Jetty(7.x.y-SNAPSHOT)
I can observe that 'new' pages (not cached) are not opened in the browser and this is expected behavior.
Than I kill the proxy server and restart it in LittleProxy mode and repeat above steps: $ ./browsermob-proxy --port 9090 --use-littleproxy=true ...
I am still able to browse internet with downstreamKbps set to 0 and this looks like a bug.