The configure would fail when cross compiling due to the regex check
automatically failing for cross compilation. Since you can't run the
regex binary check, assuming the regex library on the target platform is
working would be the only way to get the build working, or adding a
force for people to control based on their build environment.
Signed-off-by: Michael Adam <obnox@samba.org>
asciidoc is necessary as the version number is added during
configure into the asciidoc manpage sources. So simply bundling
a pre-generated manpage won't do.
Automake 1.11 (and I think 1.10b already) offers the AM_SILENT_RULES macro.
This adds switches --quiet, --enable-silent-rules and --disable-silent-rules
to configure.
--quiet makes the configure run itself quite.
--enable-silent-rules makes the compile process less verbose:
for a file that is compiled without errors or warnings, a simple
"CC main.o" is printed (e.g.). Compiler warnings and errors
are printed of course.
This makes it much easier (IMHO) to spot build problems.
--disable-silent-rules turns the silent rules off
I have set it up such that the default for tinyproxy is to build
in verbose mode (i.e. with silent rules disabled). This prints
the whole compile call command line for each source file compiled,
precisely as before.
You can also control verbose/non-verbose mode at "make" time, i.e.
after configure has run, by calling "make V=0 ..." or "make V=1 ..."
for running in silent and verbose mode, respectively.
If the version automake used to create configure is too old,
the result is unaltered, compared to the result before this change.
Wow - this is a long commit message for a 1-liner.
But since I discussed this with Mukund earlier, and he did
not seem to be too fond if this, I felt the need to justify
this change... :-)
Michael
The compiler inlines static functions as necessary anyway.
No more inline keywords exist in Tinyproxy source code. We want to
avoid using this keyword anyway.
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.
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.
