If we require information about the runtime environment, it can be
found using the uname program. And binutils can tell about what the
tinyproxy binary contains. Tinyproxy doesn't have to report this
information.
This feature will only confuse us during support, if users come to
us with a Tinyproxy build which has a differently named default config
file. This feature is not that useful anyway.
The following errors occurred when running ./autogen.sh :
$ ./autogen.sh
+ aclocal
configure.ac:18: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:386: AC_USE_SYSTEM_EXTENSIONS is expanded from...
../../lib/autoconf/specific.m4:332: AC_GNU_SOURCE is expanded from...
configure.ac:18: the top level
configure.ac:18: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
configure.ac:19: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:459: AC_MINIX is expanded from...
configure.ac:19: the top level
configure.ac:19: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
and so on for autoheader and friends.
According to the autotools docs, the proper way to handle this
is to just call AC_USE_SYSTEM_EXTENSIONS.
Michael
Moved the reverse proxy code from reqs.c into it's own files
(reverse_proxy.c). The code in reqs.c is way too complicated, so I
want to move unrelated code into their own files to simplify the main
concepts in reqs.c.
TP_ARG_ENABLE macro. Except for the transparent proxy option, all the
other options remain identical. To enable transparent proxy support
use only --enable-transparent, rather than the old
--enable-transparent-proxy.
directory, so inform autoconf of this (the AC_CONFIG_AUX_DIR and
AC_CONFIG_MACRO_DIR macros.)
Also added a bunch of portability tests discovered by autoscan.
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.
