CONNECT proxy rewrite
Does anybody know how to alter the destination of a CONNECT transaction
(in this case "secure proxy" request) in mod_perl?
$r-uri("newplace:newport") in a Trans handler doesn't seem to do it.
Unusual proxying, CONNECT munging.
We have a rather unusual proxying scheme.
In normal operation, our server has all of the slave applications' DNS
pointing to itself. Browsers are not configured to proxy. After
authentication and access control, it converts the "local" reference to
a proxy to the real server (like the wAMPC example in the section on:
"Invoking mod_proxy for Nonproxy requests"). We have this working
rather well.
In one particular instance, we need to have this server acting as a real
proxy (browsers are configured to have it as a proxy), and fall through
the rest of the code to the back end applications.
I have this working for HTTP easily enough (just don't proxyify the
requests), but SSL seems to be a severe problem, because browsers use
the "CONNECT hostname:port" for https (and then blindly copy packets
bidirectionally), rather than "GET http://host.../file".
I believe I can get this to work if, after detecting a "CONNECT" method
connection, I change the effective "hostname:port" to be localhost:443,
and force the Apache proxy to redirect to itself. Then I can handle it
through the stuff we already use.
Does anybody know how to alter the CONNECT's parameters in mod_perl so
that mod_proxy will do the right thing with it? I can "see" the CONNECT
parameter by examining $r-uri, but setting it ala
$r-uri("localhost:443") appears to be ignored.
I can't even seem to find official documentation for CONNECT. The links
(netscape and elsewhere) appear dead. I've been playing around with
some simple stand-alone proxies to test out whether the back-end stuff
will work out, but, I don't seem to be able to get them to interoperate
with CONNECT requests quite yet.
Thanks muchly.
Timing
We're using Apache/modperl as a fairly sophisticated single-signon front end for multiple web servers. I'm trying to put metrics in to log timings of parts of the process. Eg: elapsed times during authentication, authorization etc. Is there any way to time how long a translated-to-proxy request takes?
Re: Authentication and Redirection
The Ticket handling code in the Eagle Book shows how you can use redirects and cookies to remember where the user wanted to go. After authenticating, you redirect the user back to where they were trying to go. Which works, as long as you don't have to remember more than the URL the user originally issued. I shudder to think how you could support this with a, say, PUT.
Re: [OT] advice needed.
Vladislav Safronov wrote: http://vlad.narod.ru/contract.html is it really looks like a usual thing? Fairly usual, once read carefully and you realize that they're only claiming inventions that relate to them/resourced by them - the rest is disclosure, in an attempt to forestall any future problems. The problem is really in section 3. Section 1 is relatively normal, except that the last sentence doesn't limit the restrictions to work related to the company. It would, for example, prohibit you from volunteer work in an unrelated field. This is silly. Obtain written clarification. Section 2 is normal. Courts will uphold restrictions on proprietary information, provided that the definition of proprietary information is reasonable (ie: company customer information, proprietary technology etc). Not normal stuff you learn about your field. ATT came to some grief trying to enforce restrictions on "normal stuff". Section 3, first sentence is absurd. It means that you can't work in your field for two years after termination. In Canada, such a clause would be considered by the court to be a blatant attempt to deprive you of your right to earn a living in your chosen profession, and would likely cause the entire contract to be invalidated (also cf. ATT's grief). A former employer of mine tried this stunt on me and we laughed in their face. They folded. The rest of section 3 is common, but rarely enforceable (it is also probably too broad). Companies usually draft this in such a way that you're prohibited from directly competing with their business using proprietary knowledge that you obtained from them, or raping their employee base directly. In context with section 5 (which limits what inventions they have a legitimate interest in), section 4 is reasonable - they're only asking you to tell them about them so that if they do have a Section 5 interest, they can pursue it. If there is such a clash, it's better to find out about it sooner than later. Section 7 (disclosure of prior inventions) protects you, not them.
Re: Problems with proxying POST?
Doug MacEachern wrote: On Thu, 28 Sep 2000, Chris Lewis wrote: It works to proxy the HTTP to the system fine, however, POST parameters seem to get mangled and/or truncated. they should get passed through by mod_proxy, provided nobody else has read the POST data first. When I try to reference $r-content the thing appears to hang. that means something else has already read the POST data. btw, in the cvs version, multiple calls to $r-content will not block, but anything after the first call returns undef. What I actually seem to be seeing is that one of the parameters has the last two characters lopped off its value. Is there something other than $r-content or $r-read that could eat the POST data? as_string? [Given that Stronghold is a bit old, I'm endeavering to build Apache/mod_ssl/mod_perl from scratch, but it complains about not being able to load Apache.pm... Is there a step-by-step set of Solaris instructions somewhere?]
Re: Problems with proxying POST?
I figured out what it was. One of the $r-header_in() was trying to insert an Authorize header, and I didn't notice that base64_encode() tacks on a newline. After Apache core got thru with it, it ended up looking like: Authorize: Basic \n \r\n \r\n parameters which caused the destination server to start parsing the parameters two characters early, hence the last parameter had two characters lopped off the end. Sigh. Thanks all.
Problems with proxying POST?
I'm writing a perl trans handler to invoke mod_proxy for non-proxy
requests.
Stronghold 3 on Solaris 2.6, server announces:
Stronghold/3.0 Apache/1.3.12 C2NetEU/3011 (Unix) PHP/3.0.16
mod_ssl/2.6.4 OpenSSL/0.9.5a mod_perl/1.22
I'm essentially using the code from page 371 of the Eagle book without
the URL translate::
my $host = $r-get_server_name;
add some headers etc. using $r-header_in
my $newuri = Apache::URI-parse($r);
my $scheme = $newuri-scheme;
my $newuristring = "$scheme://$host" . $r-uri;
if ($newuristring) {
$r-proxyreq(1);
$r-uri($newuristring);
$r-filename("proxy:$newuristring");
$r-handler('proxy-server');
return OK;
}
It works to proxy the HTTP to the system fine, however, POST parameters
seem to get mangled and/or truncated.
I'm not actually even changing the URI, because the server's notion of
name resolution is different than the browser's.
In short: external DNS maps all of the sites this thing will proxy to do
the server itself. The server has a /etc/hosts file that remaps all of
the host names to the real servers. Hence, I don't actually have to
change the uris.
Shouldn't POST parameters go thru without playing around with
read/content?
When I try to reference $r-content the thing appears to hang.
