On 4/6/07, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Does anyone know of existing conventions around forwarding HTTP
> connections? There's X-Forwarded-For (REMOTE_ADDR), the less-used
> X-Forwarded-Server (Host). On top of that, I imagine X-Forwarded-Scheme
> makes sense (wsgi.url_scheme), though I haven't seen that used. That
> mostly leaves the idea of script name and path info, and possibly some
> other traversal path (which I don't like, but some systems use).
>
> So, there's kind of three pieces of information:
> * SCRIPT_NAME, how we got here
> * PATH_INFO, what is left to parse
> * Traversal, some indication of what you want the remote server to select
>
> So a typical setup like:
>
> ProxyPass /a http://localhost:8080/b
>
> Means that "/a" is the SCRIPT_NAME, "/b" is the traversal path. If /a/c
> is requested, it's forwarded to /b/c, and "/c" is PATH_INFO. In a sense
> X-Forwarded-Server is a kind of traversal too, as you *could* send the
> original Host header (even if that isn't the hostname you connected to),
> but many servers could be weird about that. So in effect the "real"
> Host header is either effectively garbage ("localhost") or some kind of
> traversal information. But usually it's garbage.
>
> So there's a lot of ways you could communicate this information.
> PrefixMiddleware lets you fix it up when it's wrong through
> configuration, but I'd at least like to have some kind of convention
> that could be used in addition (fixing up the environment, but with a
> middleware that doesn't require any configuration).
>
> There's a few options:
>
> /a/c -> /b/c, X-Forwarded-Script-Name: '/a', X-Forwarded-Path-Info: '/c'
> /a/c -> /b/c, X-Forwarded-Script-Name: '/a', X-Traverse-To: '/c'
> /a/c -> /a/c, X-Forwarded-Script-Name: '/a', X-Traverse-To: '/c'
> (in this option the intermediaries have to understand X-Traverse-To)
> /a/c -> /b/a/c, X-Forwarded-Script-Name: '/a'
> (in this option the application has to figure out itself that /b is a
> traversal, using whatever the native conventions/configurations are)
>
> Obviously not all options are possible. Some are going to be difficult
> with awkward servers like Apache that don't offer many options for
> fixing up the request. I'm not sure, for instance, how much you can
> change the request information in PHP. And I think you *can* change
> this information in Apache, but it might require writing new Apache
> modules, and that's no fun (even using mod_python). Though I'm not sure
> how much the request environment is trusted in Apache; there's ways to
> change it fairly flexibly with mod_rewrite, but only the environment
> dictionary.
>
> Anyway, I'm hoping someone has some opinions, because handling this
> through configuration sucks, so I really want to do something to handle
> this more automatically.
I think I mentioned before that in Aquarium I *always* did the following:
If present, use the ``X_FORWARDED_HOST`` header (i.e.
``cgiEnv["HTTP_X_FORWARDED_HOST"]) in order to override
``cgiEnv["SERVER_NAME"]`` and ``cgiEnv["SERVER_PORT"]``.
That way, it works with no configuration.
I'm sure the situation is a lot more tricky if you have multiple
levels of proxies.
By the way, this is something that was taken care of really well in
SIP, not that that helps us at all ;)
Happy Hacking!
-jj
--
"'Software Engineering' is something of an oxymoron. It's very
difficult to have real engineering before you have physics, and there
isn't anything even close to a physics for software." -- L. Peter
Deutsch
_______________________________________________
Paste-users mailing list
[email protected]
http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users
