| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This allows tinyproxy to respond to a request bound to the same
interface that the request came in on. As Oswald explains:
"attached is a patch that adds the BindSame option. it causes
binding an outgoing connection to the ip address of the respective
incoming connection. that way one can simulate an entire proxy farm
with a single instance of tinyproxy on a multi-homed machine."
Cool.
|
|
this addition follow:
The patch implements a simple reverse proxy (with one funky extra
feature). It has all the regular features: mapping remote servers to local
namespace (ReversePath), disabling forward proxying (ReverseOnly) and HTTP
redirect rewriting (ReverseBaseURL).
The funky feature is this: You map Google to /google/ and the Google front
page opens up fine. Type in stuff and click "Google Search" and you'll get
an error from tinyproxy. Reason for this is that Google's form submits to
"/search" which unfortunately bypasses our /google/ mapping (if they'd
submit to "search" without the slash it would have worked ok). Turn on
ReverseMagic and it starts working....
ReverseMagic "hijacks" one cookie which it sends to the client browser.
This cookie contains the current reverse proxy path mapping (in the above
case /google/) so that even if the site uses absolute links the reverse
proxy still knows where to map the request.
And yes, it works. No, I've never seen this done before - I couldn't find
_any_ working OSS reverse proxies, and the commercial ones I've seen try
to parse the page and fix all links (in the above case changing "/search"
to "/google/search"). The problem with modifying the html is that it might
not be parsable (very common) or it might be encoded so that the proxy
can't read it (mod_gzip or likes).
Hope you like that patch. One caveat - I haven't coded with C in like
three years so my code might be a bit messy.... There shouldn't be any
security problems thou, but you never know. I did all the stuff out of my
memory without reading any RFC's, but I tested everything with Moz, Konq,
IE6, Links and Lynx and they all worked fine.
|
|
IDENTIFIER directive and also the keyword directives.
|
|
"ViaProxyName" directive. The "Via" HTTP header is _required_ by the
HTTP spec, so the code has been changed to always send the header.
However, including the proxy's host name could be considered a
security threat, so the "ViaProxyName" directive is used to set the
token sent in the "Via" header. If the directive is not enabled the
proxy's host name will be used.
|
|
server configurable based on the destination host. [Code written by
Peter da Silva]
|
|
configuration file, rather than being hard-coded in the program.
[John M Wright]
|
|
(ErrorFile, DefaultErrorFile, StatFile) [Steven Young]
|
|
Code changes from James E. Flemer.
|
|
controlled by the ViaHeader configure directive.
|
|
tinyproxy. There is really no need for this code, since there are
perfectly good programs out there (like rinetd) which are designed for
TCP tunnelling. tinyproxy should be a good HTTP proxy, nothing more,
and nothing less; therefore, the tunnelling code is gone.
|
|
the default policy of the filter is to allow everything which isn't denied, or to deny everything which isn't allowed.
|
|
ignored if "transparent proxy" has been compiled into tinyproxy.
|
|
These directives were submitted by James Flemer for use with the new
filtering code.
|
|
|
|
with the "dnsserver" resolver.
|
|
|
|
|
|
|
|
is the correct way to do this, since grammar.c probably doesn't get
recomplied even if config.h is changed. Must look into this more.
|
|
|
|
directive in the configuration file.
|
|
|
|
|
|
|
|
|
