On 4/9/07, Ian Bicking <[EMAIL PROTECTED]> wrote: > Shannon -jj Behrens wrote: > > 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. > > I'm planning on doing this in middleware (not in every URL-accessing > function), but it's still an incomplete mapping. (I had vaguely > remembered X-Forwarded-Server instead of X-Forwarded-Host?) > > I'd probably leave SERVER_NAME and SERVER_PORT alone, and only overwrite > HTTP_HOST, which should generally take precedence anyway. Though I > dunno, PrefixMiddleware overwrites both HTTP_HOST and SERVER_NAME/PORT > currently. SERVER_NAME is generally fairly useless anyway, kind of an > HTTP/1.0 holdover. > > > By the way, this is something that was taken care of really well in > > SIP, not that that helps us at all ;) > > Do you know what they used there? I'm interested in how to communicate > the path information in particular.
(sorry for wandering off topic) A significant chunk of SIP is spent figuring out how to route messages using an unknown number of proxies. Unfortunately, it's not going to help us here. The world is different in HTTP. Best Regards, -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
