ratproxy doesn't intercept on non standard web ports

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start ratproxy, config broswer settings, navigate to target URL:3000. 
2. Target website happens to be running on port 3000.
3. Navigate to same server on default port (80).

What is the expected output? What do you see instead?

Ratproxy doesn't seem to analyze web traffic on non-standard ports (at
least it doesn't on this particular server on port 3000).  Requests to the
server on the standard port (80) seem to be correctly caught.  I can
confirm there are 2 different websites on this machine, and both are
working correctly.

What version of the product are you using? On what operating system?

1.5.1, Ubuntu 8.04, Mac OSX 10.5.4 (happens on both) 

Original issue reported on code.google.com by Christop...@gmail.com on 22 Jul 2008 at 6:16

[GoogleCodeExporter]

This is unlikely, as there is no code that would treat port 80 in any specific
manner; are you sure that your browser proxy settings are correct, and -d 
option is
applicable to both services? Please note that -d option should not include port 
names
(so if you are targeting 1.2.3.4:3000 and 1.2.3.4:80, in both cases, you should 
be
using -d 1.2.3.4).

Can you run ratproxy in this manner:

./ratproxy -a

...with no additional parameters, then try to access the :3000 service through a
browser with a properly configured proxy, and see if there is any stdout 
activity
from ratproxy?

Original comment by lcam...@gmail.com on 25 Jul 2008 at 10:37

[GoogleCodeExporter]

Thanks, will give that a shot

Original comment by Christop...@gmail.com on 29 Jul 2008 at 1:43

[GoogleCodeExporter]

Tried pointing at Apache running on 6208 with success.  Not sure why it did 
want to
work earlier.  Probably something dumb I did.

Thanks!

Original comment by Christop...@gmail.com on 29 Jul 2008 at 4:36

[GoogleCodeExporter]

Ok, marking as non-reproducible for now.

Original comment by lcam...@gmail.com on 14 Aug 2008 at 9:30

• Changed state: WontFix